Problems I'd like to see addressed in Process 2016

Note – these are my personal thoughts as I prep for the AC discussions in a couple weeks, not the “Microsoft” position. I’m pretty sure some of my colleagues disagree with at least some of the suggestions below, but I offer them to stimulate wider discussion as we build consensus on official positions for me to take wearing my AC rep hat.

In discussing possible improvements to the W3C process with a number of people in the W3C and  browser implementer communities, I often hear about 3 problems the next revision of the process document could potentially address:


1.       Innovation of new web specs is not happening in W3C; specs begin life elsewhere – often in some personal GitHub repo -- and don’t get the broad consensus and IPR protections W3C offers until relatively late in the game

2.       The W3C process in practice is too slow and contentious, often delayed for years by a small number of difficult issues, which are often corner cases or hypothetical scenarios.

3.       Recommendations are seldom maintained to reflect what works on the actual Web, hence developers turn to other resources for guidance and the W3C’s reputation as the source of authoritative standards suffers.

There’s no single process fix for these problems, but one theme cuts across most of the proposals I’ve heard:  The process now is geared toward producing normative standards that attempt to specify describe how things should work; let’s tweak it to encourage pragmatic solutions to actual web developer challenges and iterate them as the world evolves.  TL;DR – Let’s do that by making CGs an explicit part of the W3C process and encourage WGs to start with a well thought out spec before standardization; let’s relax some of the requirements about consensus and testing that sound good in principle but have too high a cost in inefficiency; and let’s take spec maintenance more seriously to ensure that Recommendations improve with age rather than go stale.

In more detail:

Incubation: The current process says nothing about Community Groups, which started as an experiment in 2011 and have become popular ways to get the right set of people involved in designing a spec with the bare minimum of process and IPR policy overhead.  The Process Document should acknowledge the existence of CGs, encourage open incubation of specs in CGs rather than assuming the process begins with a charter and blank specification, and describe specific ways a successful CG can contribute a spec that is in scope for a WG to jump-start standardization.

·         I'd like to see the Process Doc somehow (I don't have language to propose yet) encourage WGs to start with a concrete spec rather than a sense that a spec is needed. Likewise,  I'd like to see an explicit CG Contribution mechanism that parallels the (seldom used anymore?) Member Contribution mechanism to let a CG formally ask W3C to find a WG home for its spec

·          I'd like to see some criteria specified to allow / encourage a WG can take a CG spec (presumably a mature one with a Final Specification Agreement indicating a reasonable amount of support and IPR commitments) and publish it quickly as a Candidate Recommendation.

·          Picking up on a suggestion others have made (Sam and Wayne, IIRC) there should be some way for a WG and one or more CGs to align with each other, so that the CG scope is a subset of the WG scope  and there is explicit coordination among groups.  This would  make it easier for WG members to join the CG) , would help keep inter-related specs in sync, and would allow the WG to "adopt" the output of a CG once there is consensus it is ready for standardization.


Efficiency:  The WG process and W3C procedures  should encourage a bias for action, promote a culture of getting things done, and counter the tendency for consensus building to lead to paralysis.  On paper, the Process Document offers good advice for what “consensus” means and how to achieve it.  All too often in practice it means that an individual or small minority can “hold the spec hostage” with formal objections or informal appeals to the Director.  This makes sense if we think of Recommendations as Normative visions for how the future should look, but in a more Pragmatic process the Real World is  the court of appeal for WGs and CGs.  The Director can play a role in short-cutting that appeal to the Real World by nixing ideas that clearly won't pass muster (e.g. a spec that pays insufficient attention to accessibility, security, etc.) but the Director should not be in a position to pick winners and losers in technical matters, especially those which are wrapped up in business or political issues.  Better to document that there is no consensus and encourage experimentation and further discussion than to impose a pseudo-consensus.



Somewhat similarly,  the idea that specs must be formally tested to  ensure that independent developers can implement features in a way that interoperates with others looks good on paper, but has become a burden on WGs ability to get things done.  For example, as I understand it the Web Messaging spec only recently got to PR even though the spec itself has been stable and widely implemented for years.  Things got done when the WG decided that the Real World had concluded the test failures could be safely ignored.  In any event, many WGs are finding it hard to get volunteers to contribute formal tests, perhaps given the waning popularity of unit testing in favor of more holistic quality assurance approaches in the software industry, and it’s time to rethink how much formal testing is needed to advance to Rec.



In short, I believe we can make the actual spec process more efficient by taking a critical look at the Process Document and the existing social norms in W3C to look for restrictive practices that could be loosened up a bit.  From a pragmatic POV, a decent spec with actual patent commitments SOON is better than a spec with universal consensus and unit tests that work in all browsers SOMEDAY. I recognize that many in W3C will vigorously disagree, but I think it’s time for a frank discussion of which “sounds good in principle, doesn’t work well in practice” processes come at too high a cost in real world effectiveness.

Maintenance.  We’ve had a somewhat frustrating discussion  of how to improve “errata processing” and the draft Process 2015 has tweaks to make it easier to make editorial changes to a Recommendation.  But improving real world interoperability also requires more extensive  maintenance of specs to incorporate what browser implementers and website developers have learned, which might result in “breaking” changes.  That’s an uncomfortable idea from the Normative perspective, since changes that break faithful implementations of a Recommendation are something we’ve tried to avoid.  Nevertheless, and especially if we adopt some of the efficiency ideas above and get decent specs to Rec soon rather than strive for perfection someday, taking maintenance more seriously is something we need to think about while revising the process.

I don’t have a specific proposal for how to change the process document to encourage more active maintenance of specs.  A couple of ideas I’ve heard include:

·         Make interpretation / clarification of mature specs (CR, PR, Rec) an explicit, high priority responsibility of WGs; devise and use a process to request and process interpretations of how a spec would apply in concrete situations; W3C management should use its power to appoint team contacts, chairs, and (indirectly) editors to insist that WGs do indeed “eat their maintenance veggies” before they get to go out and play with new ideas.

·         Setup a more informal CG-like venue  where implementers and website/app developers can notify the group of interoperability issues, and the group sorts out whether these are due to misunderstanding of the spec by the user, bugs in the implementation(s), or errors/ambiguities in the spec.  The group ensure that their proposed resolution is logged in a discoverable place, bug in implementations are filed in the appropriate product bug tracking system, spec bugs are filed with the appropriate WG, and examples / doc improvements are recorded.

·         Keep the actual spec text in the original  GitHub repo [or the next-generation equivalent once GitHub becomes unfashionable ☺] throughout its lifecycle as it moves from a CG to a WG draft to a Rec.  If the WG loses interest in the spec once it becomes a Recommendation, the original community can continue to maintain it and potentially contribute corrections and/or a new version back to the WG to standardize. [Obviously this is only possible if the Document license is revised to allow it; I’m not advocating this at the moment, just passing on the idea]

Admittedly, lots of these points are more about W3C culture or the social norms of standardization than about the Process Document per se.  Likewise, I don’t think the formal process necessarily must change to address these problems, and arguably some proposals should be tried as experiments and only applied to the process document if they succeed.  Nevertheless, I do think that it would be useful to think about these 3 problems as part of the Process 2016 discussion, try to come to consensus on what can be done about them, and get that consensus written down somewhere.

Michael Champion
Sr. Program Manager
Microsoft Open Technologies, Inc.
A Subsidiary of Microsoft Corporation