Decision by consensus or by informed editor; which is better?

There has been discussion in the Web standards community about which is the better way to advance technical specifications: by a formal consensus process or by having all decisions made by informed editors as they informally gather a consensus. After all, the W3C has long considered consensus a core value of W3C. On the other hand, the WHATWG describes a process whereby the relevant editor makes the decisions by trying to see where the consensus is, and is explicit about eschewing formal consensus. Which approach is better?

False dichotomy!

In my view, there are advantages to either approach. Clearly when there is an excellent spec writer who works with colleagues there is tremendous efficiency to having decisions made by informed editors. People make excellent progress with this approach both in the WHATWG and in many W3C Groups, including Community Groups (which typically have a high degree of flexibility in how they approach spec writing). In W3C Working Groups it is often the case that an informed editor is able to rapidly make progress in writing a spec and produces Working Drafts with the results. A W3C Working Draft does not necessarily represent a consensus of the Working Group, as it is not a finished product of the group.

While rapid progress can be made by informed editors, W3C will not give its imprimatur that a specification is a "Standard", or a W3C Recommendation, however, unless it goes through the formal consensus process.

Billions of people and millions of developers rely on Web standards. Since the Web was invented by W3C Director Tim Berners-Lee 25 years ago, it has become a core infrastructure for personal communications, commerce, education, and entertainment. While implementers of standards can rapidly interact with informed editors, it is important that the entire ecosystem has the confidence of due process and is assured that they have their say. This ecosystem includes those who implement standards in browsers, web site developers, app developers, users, people with disabilities, corporate IT, procurement officers, telecommunication firms, ISPs, publishers, news outlets, marketing professionals, on-line e-commerce sites, researchers, educators, textbook authors, and de jure standards organizations such as the International Organization for Standardization (ISO). Significantly, the community is global.

To appreciate why this is important and necessary, it is worthwhile to review some of the key principles of OpenStand and explain their motivation.

OpenStand's five fundamental principles of standards development

• Due process. Included in this requirement is the opportunity to appeal decisions. Even the best editors make mistakes. Even when they are sincere and knowledgeable, the process needs to give assurance that there is a fair mechanism for appeal to independent arbiters. Also included in due process are processes for periodic standards review. If the entire globe relies on the standards, and the ecosystem of people that are affected is diverse, it is essential that there be underlying due process.
• Broad consensus. Included is that there are processes to allow all views to be considered across a range of interests. Again, it is the diverse range of interests that requires a consensus process. While much of the ecosystem might choose not to provide comments, they need to be assured that there are opportunities for the fair consideration of every issue.
• Transparency. Included are public comment periods before approval and adoption. It is understood that experts in spec writing are able to iterate rather rapidly at a pace that the general public could not possibly appreciate. Hence it is essential that when a major level of progress has been made in some technical area that a Working Group declares that it is timely to adopt this major level of progress as a new standard - and provides comment periods of appropriate length for the ecosystem to weigh in.
• Balance. Standards are not dominated by any particular person, company, or interest group. Hypothetically, a company, or small number of related companies might have the resources to invest in standards definition and (potentially) market power to enforce their decisions. The web, being an infrastructure dedicated for the benefit of all people needs to be assured that it remains open of undue influence by interest groups. Again, although it is certainly possible for informed editors to shield web standards from such influence, it is critical that a process guarantees that there is openness to consensus by all.
• Openness. The requirement that processes be open to all interested and informed parties appears to be one that can be achieved both by consensus processes as well as informed editor processes.

The consensus process has much to learn from Decisions by informed editors

As described in OpenStand, the consensus process has the right properties for developing standards as critical and pervasive as web standards. However, there are tradeoffs, prominent among them that introducing review and accountability to those review comments typically has an impact on speed and agility. We have much to learn from other processes such as "decisions by informed editors". We are currently looking at a prime example of that, HTML4 was standardized in 1999, and it is taking us 15 years to get to HTML5 - due to be standardized later this year. Three years ago we began revamping our processes in W3C to achieve much of the agility that the industry needs, without sacrificing OpenStand principles. Here are some of the key recent process innovations that W3C has taken to get the best of both worlds.

• Community Groups. Three years ago we introduced Community Groups for topics not yet ready for standardization. Today over 4400 people work in 179 Community Groups in a far more agile fashion. We still withhold the imprimatur of standard, however, unless the work transitions to the formal Working Group process.
• Process Revision. We have revised the W3C Process, eliminating unnecessary process steps, and giving WGs more latitude how they achieve the key requirements of wide review.
• Modularity. We recognize that large monolithic specs are difficult to advance. CSS2.1 took 13 years to complete after CSS2, so for further enhancements we have modularized the CSS spec. Several CSS Level 3 specs are already at the stable "Candidate Recommendation" level; some are already Recommendations.
• Improving W3C's plans for spec iteration. When the HTML group decided to build a plan to get HTML5 to recommendation, they simultaneously planned for a HTML5.1 in 2016. There is also discussion to modularize HTML to allow parts to proceed more rapidly.
• Errata management. Implementations evolve continuously, and we discover bugs in our Recommendations. We need to improve our processes to more rapidly reflect fixes to our Recommendations among implementers. This is done well in the WHATWG, less well in W3C and we need to improve. Based on community input, I recently raised an issue to work on improving this.

So in the end, which is better?

There are advantages to having decisions made by informed editors. But W3C must keep its commitment to the OpenStand consensus principles. For good reasons as described above. At the same time, we must improve our processes to foster agility and learning from other approaches.