- From: Shelley Powers <shelley.just@gmail.com>
- Date: Sat, 9 Jan 2010 08:31:45 -0600
- To: HTMLWG WG <public-html@w3.org>
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