[whatwg] Technical Parity with W3C HTML Spec

[Tab Atkins Jr.]

On Fri, Jun 25, 2010 at 9:23 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 25.06.2010 18:11, Tab Atkins Jr. wrote:
>>
>> ...
>> Alternately, we could continue work solely in the HTMLWG.  This would
>> not be possible unless we change the way the HTMLWG works somewhat,
>> though.  There's a *reason* that almost no technical discussion
>> happens within the HTMLWG.  If we were to pursue this option and
>> ...
>
> So what's the reason for that? Any opinion?
>
> Don't say "too much process discussions", because those are *caused* by the
> two groups not getting along too well.

To sum it up simply: too much process discussion.  ^_^

Less glibly:

Most W3C groups have one editor (or a very small number of editors,
but without loss of generality I'll just presume a single editor) for
each spec.  That one editor processes all feedback, makes all
decisions, and writes all text.  There are then a relatively small
number of other WG members who vet those decisions, and if enough of
them disagree, they can override them.  I have direct experience with
the CSSWG working this way, and my limited experience with other
groups suggests that my generalization is correct for them as well.

The WHATWG is also structured in this way.  Ian processes all
feedback, makes all decisions, and writes all text.  The steering
committee, a relatively small group of interested browser vendors,
vets his decisions and can override him if enough of them agree.

The HTMLWG is different.  It wanted to match the WHATWG's commitment
to openness and community participation, but it went about it wrong.
In most public W3C groups and the WHATWG, the "community" (that is,
everyone who's not an editor or otherwise an official member of the
group) can participate by sending comments, suggestions, and bug
reports.  The editor is still the one in charge of making decisions.
In the HTMLWG, the community is part of the decision-making process.
They can not only file bugs against things they think are wrong, they
can actually attempt to override the editor themselves.  Further, the
way the decision process is structured, it appears to be *actually*
consensus-driven, not technical-merit driven.  This produces all the
traditional downsides of design-by-committee development.  Every
disagreement produces something that satisfies no one, and most of
them are far too minor to justify the time spent on them in the first
place.

There are additional confounding factors that make the
design-by-committee process of the HTMLWG even worse.

For one, the chairs of the group do not seem willing to actually
moderate the group and remove poisonous personalities.  Anyone who has
successfully handled public input knows that poisonous people aren't
worth whatever useful technical feedback they might provide, as they
depress everyone else's desire to contribute and tend to drive away
the most useful members of the community.  I know Tantek could chime
in on this, for example, as he has significant experience moderating
the Microformats community.  In addition to the effects on the
community itself, these poisonous personalities have the ability to
manipulate the decision-making process itself due to the way the
HTMLWG operates.

For two, the WHATWG benefits from being driven by a group of people
with similar goals and overall ideas for what the web should be, and
who have a direct interest in ensuring the group makes good decisions,
as they have to implement them.  While one must always be on guard
against groupthink and should treasure dissenting voices for their
critical viewpoint, general agreement amongst the decision-making
group allows things to proceed fairly smoothly and productively.
Since the dissolution of the XHTML2WG, though, the HTMLWG has gained a
number of vocal members who have fundamental disagreements with the
direction that HTML is taking the web.  Due to the way HTMLWG process
works, each shard of thought has equal input into the decisions of the
group, we run into "too many cooks" issues, where we lose an
overarching vision binding the document together and end up with a
patchwork of decisions and rationalizations.

~TJ