Re: splits, discussions, and manic behavior

I would like to add that for someone who tries to read some of the
discussions and cannot really participate because of time / other
constraints, I find that the activities of the Working Group list this week
seemed, well, for the lack of finding a better term, weird.

I don't pretend to understand all the technical issues surrounding the
Microdata split or if Microdata is better than RDFa.
The separation of Microdata does seem logical, but all the other splits
looked like a backlash of the first split and not something that is well
thought out.

When you get months of discussions around small attributes like alt and
summary, and basically one day we find that HTML as been split in many
pieces, without discussions as such, bizarre is a small word.

That the chairs seem to be welcoming or not opposing such splits /
reorganizations is mind-boggling.

How can you strive to get Web developpers respect when these type of things
happen :-)

Note that I haven't read all the discussions and I might have missed some
resolutions of those problems.
I want to promote HTML5 to my fellow web developers and stay positive about
the working group process.
This email is to voice my concern about the way discussions are made.

Regards,

Benoit Piette
W3Québec
http://w3qc.org
http://benoitpiette.com

2010/1/9 Shelley Powers <shelley.just@gmail.com>

> 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?
> >
>
>