Revised Timeline and New Bug Priority Policy from Maciej Stachowiak on 2011-06-23 (public-html@w3.org from June 2011) (original) (raw)

Hello Working Group,

The Chairs have spent some time reviewing the Last Call Timeline, and have reviewed it with Editors of Last Call drafts (most notably Ian Hickson, who did not think he could achieve the Last Call timeline). There are three main results of this effort:

(1) The new Editorial Assistants to help speed up bug processing, already announced. (2) A new policy for bug priorities - we no longer have a specific 30 day requirement for all bugs, or a specific earlier July date for resolution of some bugs. Instead, a new priority system will say which bugs need to be addressed promptly. (3) The final dates in the timeline are pushed out some.

How does this affect you as a Working Group member? Here are a few key things to keep in mind:

• If you have a bug that needs to be addressed urgently, add the PriorityRequest keyword. These bugs will be reviewed for P1 status.
• You get some extra time for writing Change Proposals in the end part of the schedule.
• You can ask Editorial Assistants for any help you need with your bugs.

Regards, Maciej

== New Bug Priority Policy ==

Bug priorities shall have the following meanings:

P1 - Very Urgent feedback - The most critical comments (generally of a technical nature) go in this category. - Editor to address within 30 days of the bug being marked P1. Barring extenuating circumstances, bugs in this category can be escalated to Tracker Issues once the 30 days expire if not addressed.

P2 or P3 - Normal Priority feedback - All technical comments, even minor ones, must be P3 or higher (possibly excluding feature requests). - Editor to address by the next deadline for editor responses to comments, during an applicable review period.

P4 or P5 - Low Priority feedback - Generally purely editorial / non-technical comments, but may also include feature requests. - May not be addressed until CR or HTML.Next. - After the LC period and final bug review, P4/P5 bugs will be deferred to CR, deferred to a subsequent LC, deferred to HTML.Next, or upgraded to P2/P3. - Feature requests or editorial comments could be promoted to higher priority; the editor can still reject the comment in that case.

How setting priorities works: (1) A commenter files a bug. Default initial priority for newly filed bugs shall be P3. (2) A commenter may voluntarily set the initial priority of their own bug to P4 or lower. (3) The Editor or Editorial Assistants may freely adjust the initial priority, resulting in a revised priority unless the bug has been has been assigned a final priority by the HTML WG Chairs (see below). (4) If the bug originator or an HTML WG Member would like to see the priority raised from the initial or revised priority (e.g. to P1, or back to P3 if lowered to P4), they should do so by adding the PriorityRequest keyword to the bug and explaining in a comment what priority they request and why. The Chairs will ensure that Editors and Editorial Assistants get automated mail in such cases. (5) If asking for a priority escalation in this way is not satisfactory, the WG Members may post to public-html and appeal any decision by the Editor or Editorial Assistants to the HTML WG Chairs. (6) If there is an appeal to the Chairs, the Chairs may determine the priority for a bug. A priority set by the Chairs is final.

== New Timeline ==

• May 24, 2011 - Opening of Last Call review period - May 24-Aug 2 (10 weeks)
• May 24, 2011 - Commence processing of open Tracker Issues that exist at the start of Last Call Consequences of missing this date: Delay in processing of open Tracker Issues at the start of Last Call will put subsequent dates at risk.

(10 weeks)

• Aug 3, 2011 - Cutoff for bugs to be considered as Last Call feedback. Consequence of missing this date: bugs beyond this date will NOT be treated as Last Call comments. The Chairs could grant exceptions on a case-by-case basis, but in general there is no guarantee of a bug filed after the cutoff being settled during the Last Call period.

(1 day)

• Aug 4, 2011 - All bugs filed by the cutoff will be moved to newly created LC1 components to clearly demarcate what is LC feedback.

(2 weeks)

• Aug 18, 2011 - Editors and Editorial Assistants to ensure that all bugs filed by Aug 2 have their correct revised priority assignment. Consequences of missing this date: bugs will be assumed by the Chairs to have their initial priority set as intended.

(1 day)

• Aug 19, 2011 - Working Group commences full review of all LC bug priorities. WG members may object to deferrals or priority choices. Note that WG members may object even sooner, but all bugs should have a revised priority by this date.

(2 weeks)

• Sep 2, 2011 - Deadline for objecting to initial or revised priority settings or deferrals. Chairs will reconsider based on objections. All time ranges on the timeline marked with [FLEX] may change if, after review, LC feedback is significantly above the expected level for any draft. Note that W3C precedent is that feature requests may be deferred, but significant editorial comments generally should be addressed. Consequences of missing this date: deferrals and priorities not objected to are assumed to stand.

(2 weeks)

• September 16, 2011 - Chairs complete review of priority or deferral objections. Consequences of missing this date: this would be solely a failure by the Chairs, so we would publicly eat crow and plot a new date.

(15.5 weeks) [FLEX]

• December 31, 2011 - all bugs remaining in LC1 components addressed by editors Consequences of missing this date: bugs still open past this date can be escalated to Tracker Issues immediately if the originator so chooses.

(2 weeks)

• Jan 14, 2012 - cutoff for escalating bugs for Last Call consideration - all Tracker Issues in Tracker, calls for proposal issued by this date Consequences of missing this date: any further escalations will not be treated as a Last Call comment.

(4 weeks) [FLEX]

• Feb 11, 2011 - every issue has at least one Change Proposal Consequences of missing this date: Tracker Issues will be closed without prejudice and marked POSTPONED; can be reconsidered during second LC or for a later version of HTML.

(4 weeks) [FLEX]

• March 10, 2012 - all calls for counter-proposals complete Consequences of missing this date: if any issue has only one proposal, we will call for consensus on that proposal

(4 weeks) [FLEX]

• April 7, 2012 - all Trcker Issues resolved; next step resolution presented to HTML Working Group Consequences of missing this date: this would be solely a failure by the Chairs, so we would publicly eat crow and plot a new date.

(2 weeks)

• April 21, 2012 - fixable resolution objections addressed; if all goes well, next step resolution carries Consequences of missing this date: try next step resolution again.

• April 22, 2012 - after this point, every change to the spec will require a prior bug report; the Chairs will work out details and may set this date earlier in the Last Call processing

Total slip relative to our previous timeline: 11.5 weeks; slip may increase if LC feedback is greatly beyond expectations and Chairs choose to re-plan.

Received on Thursday, 23 June 2011 15:32:15 UTC