W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2010

[Bug 10230] Decisions need to be made in timely manner

From: <bugzilla@jessica.w3.org>
Date: Sat, 14 Aug 2010 22:51:42 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OkPZm-0007f4-0s@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10230





--- Comment #5 from Shelley Powers <shelleyp@burningbird.net>  2010-08-14 22:51:40 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #0)
> > > > 
> > > > Or, if the burden on the co-chairs is too
> > > > much, then the Decision Process will have to be changed in order to lessen the
> > > > co-chair impact on the Decision Process critical path.
> > > 
> > > Proposal?
> > 
> > The first proposal would be to add a couple of more HTML5 spec editors. Right
> > now, the count of bugs is heading towards 400. When the editor does a "blitz"
> > on the bugs, which he did once before, he doesn't give the appropriate
> > attention to the bugs, nor work to resolve problems. Instead he seemingly 
> > arbitrarily makes decisions, and provides little or no rationale for the
> > decisions.
> > 
> > These actions end up generating more issues, which the group no longer has time
> > to resolve. These actions also generate more contention, which the group
> > definitely no longer has time to resolve.
> > 
> > Secondly, the co-chairs need to set deadlines for actions, and stick to them.
> > In fact, all issue actions need to have deadlines, and should be adhered to. Of
> > course, problems happen, and time conflicts occur, but as a general rule,
> > deadlines should be taken seriously. 
> > 
> > Thirdly, I would recommend that the HTML5 co-chairs bring in individuals from
> > outside the working group to help with working group decisions. There are too
> > many for the co-chairs, and I also can't help thinking that fresh perspectives
> > would be beneficial to the process. And spreading the work out a bit could also
> > help ensure more timely resolution.
> > 
> > Fourth, the group needs to be re-activated, and people re-engaged. Compare the
> > august email postings this year with past years. No, the dearth of interest is
> > not because all the problems have been resolved. Thankless task or not, it is
> > the responsibility of the co-chairs to ensure momentum continues in the group.
> 
> I wanted to provide additional clarification on these bugs, to ensure timely
> resolution:
> 
> The addition of more editors would mean that more time could be given to
> individual bugs. More time means that more rationales would be provided, and
> that the editor could also take more time to work with the bug filer to resolve
> the bug. This prevents additional issues, which would help lessen the burden on
> the decision process. 
> 
> The deadlines are a given: the co-chairs should be assigning deadlines for
> their actions, as much as they assign deadlines to others. And a deadline
> should be treated as such. Including deadlines given to task force sub-groups. 
> 
> Increasing the pool of those who make decisions would ensure more timely
> decisions. Adding fresh perspectives could, hopefully, ensure lack of bias, as
> well as ensure that all interested web communities interests are being met. The
> issue resolution process should be more than just a way to get this thing to
> last call -- it should be a way to ensure that all members feel their concerns
> are addressed. 
> 
> Lastly, the more discussion on the bugs in the list the less likely they'll end
> up as issues, the more likely the outcome for the issues will be easier to
> derive, the less time necessary to spend on both issues, and issue decisions. 
> 
> One of the big problems for all of this is that the HTML WG email list is only
> for members, but the HTML Comment email list is ignored by members. Compare
> this to the WhatWG email list, where anyone can participate, and key members of
> the HTML WG actually pay attention to what's happening in the list. However, in
> that list, only one person has decision making capability, and those who might
> override him, either never do, or have stopped participating altogether. 
> 
> The W3C HTML WG is both too formal, and not formal enough. Too formal, in that
> you have to be a WG member to actively participate in discussions. Not formal
> enough in that anyone can join the group, and so you have 400+ members, 90% of
> whom haven't been actively involved for who knows how long. 
> 
> Weed out the inactive members, open the list for discussion by all interested
> people, appoint a group of moderators who quickly break up non-essential
> discussions (yes, even if people like myself get peeved at being yanked to
> www-archive), create a small, but effective decision committee to offload some
> of the co-chair burden, and get people engaged in solving problems again. 
> 
> This should help with some of the co-chair bottleneck within the HTML WG
> decision process.

The IETF HYBI group appointed a secretary[1] to ensure discussions are on
topic, and also that changes agreed to by the group are made in a timely manner
to the document(s). 

I don't know what magic must occur within W3C, but the creation of additional
positions with selective jobs could help with bottleneck: a couple of people
who ensure that discussions stay on topic; a couple of others to ensure that
actions are completed in a timely manner. I would suggest that those who ensure
topics stay on topic should be from among the more patient and diplomatic
members, while those ensuring actions occur in a timely manner should be among
the most organized.

These actions won't help if bugs are being ignored by editor(s), but could help
with other bottlenecks. 

If you want additional suggestions or proposals, let me know.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg03195.html

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 14 August 2010 22:51:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:21 UTC