Re: splits, discussions, and manic behavior

I forgot to add that the end result of all this manic activity this
week is I believe the bugs I initially wanted to create as issues,
were mostly rejected, after the rather interesting mechanizations this
week. This does mean that I can now add these as issues, which I
wanted to do in the first place.

By adding the items as issues, I can then submit formal change
proposals, and the group will be able to have a discussion on the
proposal, and submit alternatives or suggested changes. The discussion
will have a finite end, and a specific purpose, which will, hopefully
provide some focus.

We may end up having consensus, but if we do, it will occur formally,
be recorded, with a directive to the editor to make whatever change.
If not, we'll have a poll, where everyone will be heard. Then the
results of all the work will go to the three co-chairs, who will
evaluate the effort.

Though I may not be particularly happy with the co-chairs this week,
because of the damaging events, I happen to trust that they'll do an
exceptionally good job of weighing the arguments, and coming out with
the best decision for the group. Not just because I agreed with them
on the Microdata decision, but because their individual strengths and
backgrounds balance each other, and all three have the best intentions
when it comes to this effort. I trust them.

So I should convert the bugs into issues, but right now, I don't quite
have the motivation to do so.

Shelley

On Sat, Jan 9, 2010 at 8:18 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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:32:18 UTC