splits, discussions, and manic behavior

I was the one who introduced most of the bugs about removing elements.
Some of the removals had to do with creating separate specifications
(such as Communications, which should go to the Web Apps group), and
the Browser Core (or however it could be called, which needs its own
group), and some I wanted deleted, because they really don't fit into
"HTML" (hidden attribute, which is redundant, progress, meter,
details, and possibly even figure). Perhaps I should have used
different words in the titles, but I believe in the bugs I stated my
preferences for each.

I also supported the Microdata split, and the 2D canvas split, but for
the latter, the one being managed by Doug Schepers and Eliot Graf, at
http://dev.w3.org/html5/canvas-api/canvas-2d-api.html. A separate
email list was formed for the effort, and supposedly a separate group.
I wasn't expecting that, all of a sudden, Ian would do his own
version, and that we would continue owning it. I definitely wasn't
expecting yet another split out spec that was controlled solely by Ian
Hickson.

Nor was I expecting all of my bugs to be ignored for over two months,
and then this manic flurry of activity this week: of ripping the specs
apart and cramming them back together again. I definitely did not
expect such behavior in a mature organization like the W3C. Such
behavior is amateurish, and will, rightfully so, generate concern
about the maturity of HTML5--especially when combined with what's
happening at the WhatWG, where evidently, the organization has decided
to fork HTML, and bring about two separate versions of HTML5.

Excuse me: one version of HTML5, and one version of Super HTML.

To return to the W3C work, the suggestion has been made in a couple of
emails that we begun discussions about major changes on the email
list. The suggestion sounds reasonable, but there are two problems
with this approach.

The first is that there is nothing about informal emails that provides
specific deliverables. Our change procedure is based on items
beginning as bugs and then going through the issue tracker if the
editor disagrees. I brought up concerns about the fact that this
procedure does not ensure that major items are discussed on the group
first, and suggested that major items should not begin as bugs, but as
issues. The reason I made this suggestion is that issues have a
formality to them that ensures we don't fall into circular discussions
that seem to go on forever. Issues are tracked, they are supposed to
generate actions, they can have formal change proposals attached, they
can result in polls, and Working Group decisions. There is a level of
finite control attached to issues that does not exist with many of our
discussions in emails.

Speaking of discussions in emails, this leads to the second problem
with email discussions: lack of equal respect for all participants.
One only has to read the WhatWG IRC a few days to see one person or
another from this group pontificate about how he "tunes" out this
member of the group or that.

There is nothing in an informal email discussion that demands
attention from all relevant parties. In fact, as we've seen this week,
when I triggered the bug system to cc the group on my bugs, and the
subject line of the emails reads "Remove the Details element", there's
nothing that guarantees the relevant parties will pay attention,
especially when the communication is associated with those who are
"tuned out", or the participants are involved in some debate in some
other thread.

If a discussion is started, all too often I've seen various members of
this organization ignored, even if they are the person responsible for
the action that initiated this discussion. There is definitely a class
system at work in this organization--and one that ensures that that
any email discussion is unequal, at best.

The change proposal process, though, equalizes the process: via change
proposals, as well as alternate proposals; in discussions associated
with the formal change proposals; having our say in the polls; our
arguments evaluated on their strengths, rather than their popularity,
or the popularity of the individual making the proposal.

Regardless, none of this matters if we wake up one day and found one
specification, suddenly, split into six, with little care to quality,
or damage caused by the resulting split. Then when it's pointed out
that such split is harmful, the result is reversed, and the bugs that
are supposedly the "cause" of such aberrant actions, dismissed out of
hand.

Yet, if these had been managed properly, formally, I bet we would find
this group more in agreement or not--if arguments were allowed to be
heard, if formal change proposals were allowed to be given, if the
HTML5 author didn't act so abruptly, and unilaterally.

Over two months, no activity, and then hundreds of bugs, some
extremely major, supposedly fixed in a matter of a couple of days:
tell me something for those of you who don't work for browser
companies, where seemingly this is acceptable behavior, what would be
the reaction of your folks be to this type of behavior? Would you feel
confident of the applications created? Would you feel that team work
was supported, and the result was a quality effort?

Yet, not only has this behavior been seemingly acceptable in this
group, I've seen one of the co-chairs encourage it, and little from
the other two.

What matters how many discussions we have, when this group is so out of control?

Received on Saturday, 9 January 2010 14:19:01 UTC