List of Concerns

Process Implementation

• Educational materials for Working Group Chairs might help the Process be understood better and implemented more consistently.  A training program, expanded FAQ, and/or a “best practices” document might help the Chairs carry out their duties with less individual interpretation.

• Aspects of the Process are inconsistently enforced.  The Process includes materials such as good standing rules, 'heartbeats', and perhaps others that are enforced on an irregular basis. Although some Chairs find it useful to enforce good standing to ensure attendance at discussions, many do not. Note that there are no tools for keeping attendance other than what each Chair creates.

• Do the roles & responsibilities of identified people need updating?  It may be beneficial, or it may not, to more specifically define the roles of Chair, Editor, and Team Contact. Some groups use a “strong editor” model where the Editor is given a lot of flexibility to update the text and include issue resolutions until somebody objects. Other groups inspect and approve every proposed change that goes into a Working Draft before incorporation.

Process clarity

• Going to Last Call (LC) is misleading for Candidate Recommendation (CR) changes.  People generally feel this is an arbitrary mandate in the process. The way the process document reads, it seems to some like an arbitrary penalty for making changes at the CR level.

• How should implementation integrate into process?  From an efficiency and testing point-of-view, it is good to obtain implementation early in the process and well before the call for implementations (Candidate Recommendation). Often implementation of a feature exposes further issues which might be beneficially resolved. An early implementation might clear these up before the initial Last Call and so reduce the potential for multiple loops from Candidate Recommendation and back to last Call. Some have proposed that a document might be introduced into Last Call in an incremental manner with just those portions that have been changed subject to review and exclusion.

Complexity of Process Document (elements that may be removed)

• Heartbeat requirement not enforced or useful.  The nature and the purpose of the 'heartbeat' documents may be misunderstood, and the Process Document provides little guidance. Is a 'heartbeat' just a document driven by the calendar intended to show progress? Is it a document that is intended to demonstrate some working group approved checkpoint? It may be that something else, such as an approved committee draft, might beneficially replace the heartbeat requirement.

• Process Document too big? The Process Document includes material that is pure process, material that is variably enforced, and other material that relates to “governance”. Perhaps these different types of content should be separated.

• Separate out core process from standing rules? Reorganizing the Process Document may help readers; or dividing it so that the basic process steps can be seen without having to read through all the detailed information. A more structured HTML document with more hierarchy may be more to the liking of some readers.

Speed of document production (minimization of delays)

• Schedule delay due to process. There are many reasons for schedule delays: the time it takes to resolve issues, the time it takes to pass publication rules checking, the time waiting for a team member to move material to the TR space, the time waiting for the webmaster to publish, the process-defined minimum review periods, and so forth. These delays frustrate Working Group members. Can we identify more efficient ways to move things along? In particular, it may be useful to illustrate and or expand the areas where review and exclusion periods may overlap with on-going committee work.

• Issue resolution takes (too much) time.

The challenge is to find the correct answer even if it is not convenient or quickly at hand.

• The consensus process confuses and/or frustrates some participants. Some interpret consensus as seeking unanimity rather than general agreement – that is, the general consent of the group.

• Chairs decide when to use a vote, which some are reluctant to do until an extended period of time has passed.

• Charters almost always underestimate the amount of time needed for issue resolution.

• Chairs could be more aggressive in finding ways to resolve issues.

• Lack of test cases is a major contributor to schedule delay.  If tests are not created until the Candidate Recommendation (CR) timeframe, then it is likely delay will occur, since the process-defined review period is relatively short. Since test cases are one factor of testing that is necessary for a spec to progress from Candidate Recommendation to Proposed Recommendation, they are a key process item determining speed to Recommendation. Test case production is often under-resourced.

• The process may not adequately encourage tests & testing. This is closely related to the “Lack of test case” issue. We may want to consider that test cases be developed earlier in the process. The availability of resources for the development of tests seems to be an issue in some cases. Should a charter “supporter” be expected or perhaps required to commit resources, including test resources?

• Publication rules place an (unreasonable?) barrier

Publication rules include a variety of screening steps intended to ensure document integrity. These screens include diverse areas such as the structure of the document, the status of the document, references and link checking amongst others.

• Format restrictions.  Can a spec be published in the format that it describes? What is the impact on tools?

• # of steps to pass.  Some further integration of document validity checking may be interesting, but that may also work against format flexibility. An XML-based document may be easy to machine process but may not be the preferred format for document editors.

• Links to other docs.  How are links to other documents maintained? Are there restrictions as to what sorts of documents may be linked? Is it necessary to identify normative vs. informative references?

• Normative references.  What are the rules, if any, regulating the references to external documents? Is it necessary to require a specific maturity level in documents that are referenced? Do W3C documents have any special standing?

Contextual/Social Framework

• What are the various audiences for documents? There seem to be several audiences for the documents at different levels of maturity. For example, the agile developer community has different needs from the international de jure standards community. There is some question as to the nature of a “review” level document. The Patent Policy uses specific maturity levels to trigger exclusion declarations which may complicate usage or confuse purposes.

• Is there value to the Advisory Board (AB) & Technical Advisory Group (TAG)? Or, have they outlived their usefulness?

• Is the TAG providing expertise desired from the point-of-view of the specification development communities?

• Does the AB adequately represent the diverse interests of the membership, and should we change something?

• Are some constituents 'more equal' than others?

• Desire for stable reference.  Some communities desire a reference that is stable and controlled from release-to-release. These might include, for example, end users and international standards bodies. It may be acceptable for some to say that they have implemented all of the HTML5 spec as of a certain date, but others might be interested in a document that actually corresponds to that implementation level and is useful to ensure interoperability with other implementations. Others describe a form of document that is described as a "living" specification. Stable progressed and final specifications, by contrast, are supposed to be "dead" and stable.

• Find ways to allow experimentation. A number of participants have indicated, by their actions, that there needs to be a way to experiment with increased functionality, to allow innovation. Some have proposed that allowing specifications to be “forked” is the way to  do this. Others have used vendor prefixed keywords to introduce new functionality. There are problems with both of these solutions, problems such as achieving interoperability when unprefixed keywords are used before a specification is stable versus the pain of having multiple prefixes extent when stability seems to be achieved. What is a good way to allow innovation and experimentation as well as interoperability?

• What is the social contract with contributors to specifications. Within the Open Source community, there is a social contract that anyone can take their work elsewhere; for example as a fork of the source files. Some believe that the same should hold for contributions to specifications; that is, one should be able to ‘fork’ the specification and take that fork in another direction if they are unsatisfied with the specification they are forking. In particular, if they believe that the specification is becoming “stale” due to lack of attention by the owning organization. Opponents to ‘forking’ argue it is important to prevent the creation of competing versions of the same specification.

• Official drafts are disconnected from some audience needs. The rules for placing a draft (Working or higher) on the Technical Reports (TR) page (http://www.w3.org/TR/) require a resolution to do so by the Working Group. Many WGs now do all of their technical work in a public space so their work is always visible. With both public drafts and the TR Page, some users of the documents become confused as to where to look. In addition, because the work is public, sometimes WGs fail to update the TR Page with a current draft. Should the TR page point to public drafts (as well as WG sanctioned ones)? Should the tools make publication on the TR Page very convenient? Should there be some sort of “time-line” display of documents that might be browsable by all parties -- that incorporates all versions of a document, clearly marked as to status?

• Process document does not match modern development methodologies & tools. The Process Document was written with stable (a.k.a “dead”) documents in mind. Modern development approaches are much more incremental in nature. Using a “living” document has been proposed as have modular and incremental standards development.  Might a document exist at several levels of maturity in some combined manner -- perhaps sections described as "Recommendation", sections marked "For test implementation", others perhaps marked "Experimental"? Might multiple versions of the document exist each one at a decreasing certainty of stability?

• Do we have the right processes for starting or stopping groups and work?

• Creating charters.  It is not clear that the current chartering process helps make good resource usage decisions. The process tends to perpetuate where the Web has been rather than help it move to where it should be and the AC does little to select appropriate work and to limit the commitments made in a charter to that which can really be accomplished.

• Ending a group.  It is often unclear when a working group should be closed, especially as it nears the end many exist in an inactive but open status awaiting potential comments.

• New possibilities.  Now that Community Groups exist, is there a need for changing the Working Group formation process in some manner?

Community

• Can we improve input from 'horizontal' groups (WAI, I18N, ...). Horizontal groups have the difficult task of helping with the development of all the specifications being developed within the W3C. These groups have expertise that is (often, unfortunately) not well represented in the WG developing a particular specification. How can the concerns of the ‘horizontal’ groups best be input into the process? Review at Last Call can be too late.

• Last Call (LC) may not be as useful as intended. It seems there are two purposes for Last Call. One is to trigger patent exclusion calls; another is to produce a review document for external entities. These purposes are unrelated.

• What should trigger external review? External review is intended to ensure that audiences that are not participating in every day specification development have a chance to review the document and to raise issues that concern them. The Process document has strong requirements to enable these reviews. Should some of these requirements be loosened, especially when development is done in the public and incrementally.  Should there be a different trigger than Last Call for such reviews? 

Intellectual Property Rights (IPR) considerations

• Charter scope & IPR commitments. Can working groups produce a spec that includes areas beyond that which is described in its charter? If not, should patent exclusions be applied to the charter instead of the specifications? Should the call for exclusions be brought to the charter commitment timeframe?

• IPR 'calls for exclusion' may not be at the correct time in the Process. IPR 'calls for exclusion' occur at specific publication events. There might be a need for a limited development license to encourage implementation prior to Rec. Calls for exclusion create uncertainty windows in the spec production process.

• Spec maintenance (including IPR commitments).

• When a version of a spec is maintained, do we have adequate commitments in place to ensure all of the prior licensing commitments from the previous edition are maintained?

• Are exclusion calls in a maintained document limited to the changed material?

• Are exclusion calls for a maintained document necessary?

• What degree of change is appropriate for a maintained document (such as the potential addition of new features)

• Substantive change is not supposed to be part of specification maintenance however if the change is not substantive there is little motivation.