Re: Revised Timeline and New Bug Priority Policy

Hi Paul,

 please note the link to change proposal [
http://www.w3.org/html/wg/wiki/ChangeProposals/notitle] for issue 80 is
outdated.

should point to http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2

regards
stevef

On 19 January 2012 14:46, Paul Cotton <Paul.Cotton@microsoft.com> wrote:

>  >- 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:Paul.Cotton@microsoft.com]
> *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:* public-html-request@w3.org [mailto:public-html-request@w3.org] *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.****
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html