2012-10-24 17:43 UTC Consensus
I recently wrote the following in an e-mail, but it seems suitable for a wider audience. tl;dr: I think it's more important for specs to be technically sound than it is to get consensus on them.
Consensus (also known as "design by committee") is a terrible way to design a language or platform. Committee design dilutes responsibility and blame (everyone just starts saying things like "yeah, I didn't like it, but we had to do that to get consensus") while letting everyone take credit for everything (since their ok is necessary to get consensus), which makes it an attractive proposition for people who want to further their careers without really doing any work. You also end up with people who arbitrarily disagree with things just so their voice is heard, you get political decisions ("I'll agree to your pet feature if you agree to mine"), you get specifications that feel like they've been written by fifteen people all with different styles, in short, you end up with a technology that doesn't know what it is and doesn't do anything well.
You get much better results by putting all the blame on one person, who then feels extremely motivated to not design something that sucks, while diluting the credit to all the people who are contributing solid technical information. This model pushes the people who don't want to do real work away, improves the quality of the final product, and provides an environment where if there are multiple completely divergent viewpoints, they can compete rather than being forced to ruin each other.
The other problem with "consensus" is the question of consensus among whom? In practice in specification working groups it ends up being consensus amongst those who bothered to show up, but this is almost always a non-representational group. For example, in some groups (e.g. W3C's WebApps group) implementors tend to be over-represented while authors and users are virtually absent. In others (e.g. IETF's hybi group) implementors of one conformance class (in this case servers) tend to completely outweigh implementors of another whose buy-in is actually more critical to the success of the technology (in this case browsers — WebSockets would have gone nowhere if none of the browsers implemented it, but would still have been a roaring success if only a fraction of server vendors cared to support it, since anyone can implement the server side). I've been in situations, e.g. the sXBL fiasco, where I've represented all the browser vendors in a group consisting of a dozen or more people, and if everyone agreed to something but me it was considered that we had consensus, even though in reality it meant none of the implementors were on board.
This is why "consensus" isn't a value I hold highly. Specs shouldn't be designed to consensus, they should be designed so that they end up solving real problems.
(Note that this does mean that there are certain stakeholders who need to be on board — e.g. a majority of implementors for the key conformance class. So for example, for HTML, I need to make sure that whatever I spec is something that the bulk of implementors want to implement, otherwise it goes nowhere. But that's not consensus, it's just that "we won't implement that" is highly relevant technical feedback.)