This is personal copy of the email that I just sent to the HTML WG reminding WG 
members that the last date to provide a change proposal for a re-open request 
is Sat Feb 11.

I believe you have one or more re-open requests that need a change proposal as 
per the list at:

http://dev.w3.org/html5/status/new-information-status.html

Please let the Chairs know if you have any questions on this matter.

In addition we would obviously appreciate receiving any notifications of how 
you plan to progress your re-open requests.  You should send such notifications 
to [email protected]<mailto:[email protected]>

/paulc
HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Paul Cotton [mailto:[email protected]]
Sent: Thursday, January 19, 2012 9:46 AM
To: HTML WG LIST
Subject: RE: Revised Timeline and New Bug Priority Policy

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

We have 11 requests for reopening based on (alleged) New Information:

http://dev.w3.org/html5/status/new-information-status.html


Six of these requests were not accompanied by a Change Proposal.  WG members 
are reminded that Sat Feb 11 is the last date for providing change proposals 
for any of the reopen requests as per our Last Call Timeline.

/paulc
HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Paul Cotton 
[mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Wednesday, January 11, 2012 2:00 PM
To: HTML WG LIST
Subject: RE: Revised Timeline and New Bug Priority Policy

>- 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.
WG members are reminded that Sat Jan 14 is the last date for escalating Last 
Call bugs to be Last Call issues.

WG members are reminded that if they add the TrackerRequest keyword to a bug in 
order to escalate the bug they should also supply the Title and Text for the 
new issue [1].

/paulc

[1] http://lists.w3.org/Archives/Public/public-html/2011Jun/0316.html

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]]<mailto:[mailto:[email protected]]> 
On Behalf Of Maciej Stachowiak
Sent: Thursday, June 23, 2011 11:32 AM
To: HTML WG LIST
Subject: Revised Timeline and New Bug Priority Policy


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.

Reply via email to