This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A troubling component of the HTML WG Decision Process is that co-chair activity is incorporated into several places in the Process critical path. This means that there are potential bottlenecks for co-chair activity at various times: when calling for change proposals or alternative proposals; when calling for consensus; when initiating a survey; when responding to a survey. In addition, others participating in the Decision process, such as those creating proposals, are given deadlines, no deadlines are ever given the co-chairs to complete their tasks. There are now several actions awaiting co-chair intervention and response--and the number is growing. Some change proposals were submitted months ago, but are still given time for counter-proposals. Some completed proposals and counter proposals, are still awaiting surveys. Several survey items have been awaiting co-chair decisions for over two months. In addition, we have no idea when a response will be forthcoming, as deadlines for the co-chair actions are invariably given "NA". Either the co-chairs will need to hold themselves to a given schedule on their actions--recorded, and adhered to. 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.
An additional comment I wanted to make: Several times a deadline has passed but the co-chairs have allowed members of the group to submit proposals--or to put off submitting a proposal or counter-proposal--past the deadline. Deadlines should be seen as deadlines. Though there should be some flexibility when a deadline is agreed to (not all issues can result in a proposal within 30 days), once a deadline is made, it should be adhered to unless there are very special circumstances, such as illness, or problems related to work or family.
(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?
(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.
(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.
(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
The Chairs believe we have addressed this through the following: 1) By establishing a timeline for pre-Last Call review 2) By meeting said timeline. 3) By establishing a timeline for Last Call itself: <http://lists.w3.org/Archives/Public/public-html/2011May/0162.html> Sam's remarks on this were: "We described what we planned to do and met those dates. We have since published a set of dates for the next several months. We are contemplating revising those dates based on feedback. If anybody would like to provide additional feedback on those dates (e.g., proposing an intermediate milestone with appropriate cut-offs etc) for issues that people believe need to be handled on a different schedule, we will respond to that request." I agree, therefore I am marking this as FIXED.
(In reply to comment #6) > The Chairs believe we have addressed this through the following: > > 1) By establishing a timeline for pre-Last Call review > 2) By meeting said timeline. > 3) By establishing a timeline for Last Call itself: > <http://lists.w3.org/Archives/Public/public-html/2011May/0162.html> > > Sam's remarks on this were: > > "We described what we planned to do and met those dates. We have since > published a set of dates for the next several months. We are contemplating > revising those dates based on feedback. If anybody would like to provide > additional feedback on those dates (e.g., proposing an intermediate milestone > with appropriate cut-offs etc) for issues that people believe need to be > handled on a different schedule, we will respond to that request." > > I agree, therefore I am marking this as FIXED. What you've done is put on blinders(In reply to comment #6) > The Chairs believe we have addressed this through the following: > > 1) By establishing a timeline for pre-Last Call review > 2) By meeting said timeline. > 3) By establishing a timeline for Last Call itself: > <http://lists.w3.org/Archives/Public/public-html/2011May/0162.html> > > Sam's remarks on this were: > > "We described what we planned to do and met those dates. We have since > published a set of dates for the next several months. We are contemplating > revising those dates based on feedback. If anybody would like to provide > additional feedback on those dates (e.g., proposing an intermediate milestone > with appropriate cut-offs etc) for issues that people believe need to be > handled on a different schedule, we will respond to that request." > > I agree, therefore I am marking this as FIXED. Frankly, all I see are some dates and some pronouncements, not solutions.
(In reply to comment #7) > Frankly, all I see are some dates and some pronouncements, not solutions. Achieving the LC date set months in advance seems like a concrete success, not just a pronouncement.