html5/decision-policy decision-policy-v2.html,1.16,1.17

Update of /sources/public/html5/decision-policy
In directory hutz:/tmp/cvs-serv20593

Modified Files:
	decision-policy-v2.html 
Log Message:
Define procedure for entering Last Call 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9554


Index: decision-policy-v2.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v2.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- decision-policy-v2.html	16 May 2011 03:46:46 -0000	1.16
+++ decision-policy-v2.html	16 May 2011 04:36:24 -0000	1.17
@@ -109,7 +109,7 @@
 </p>
 </dd>
 
-<dt>2. Editor's Response</dt>
+<dt id="basic-step-2">2. Editor's Response</dt>
 
 <dd><p>Editors will give an initial disposition to incoming bugs. When
 an editor gives the initial editor's response, he or she should
@@ -214,7 +214,7 @@
 commenter. Once reopened, the issue returns
 to <a href="#basic-step-1">step 1</a>.</dd>
 
-<dt>5.d. No: Escalate to Issue</dt>
+<d id="basic-step-5d">5.d. No: Escalate to Issue</dt>
 <dd><p>If the commenter is dissatisfied with the resolution and does
 not believe it is productive to ask the editor to reconsider, he or
 she may ask to escalate the issue to the issue tracker. A commenter
@@ -323,7 +323,7 @@
 from <a href="#basic-step-7a">step 7a</a> <b>** This is an endpoint
 for the escalation process. **</b></dd>
 
-<dt>1. Raised Issue: Chairs Solicit Proposals<dt>
+<dt id="escalation-step-1">1. Raised Issue: Chairs Solicit Proposals<dt>
 <dd><p>When an issue enters it starts in the RAISED state. The chairs
 solicit volunteers to write Change Proposals when the issue is
 raised. For pre-existing issues, we will ask for volunteers in a
@@ -380,7 +380,7 @@
 <p>If a Change Proposal is not complete by the deadline (default one month), proceed to <a href="#escalation-step-2a">step 2.a</a>.
 </dd>
 
-<dt id="escalation-step3">3. Discussion</dt>
+<dt id="escalation-step-3">3. Discussion</dt>
 <dd><p>The Change Proposal (or multiple Proposals) may be discussed
 and revised for a reasonable period. Authors of Change Proposals are
 strongly encouraged to seek consensus and revise their Change
@@ -391,7 +391,7 @@
 for Consensus (<a href="#escalation-step-4a">step 4.a</a>). If there
 are obvious objections or other alternatives, the chairs may instead
 issue a Call for Alternate Proposals
-(<a href="#escalation-step-4b">step 4.b</a>).</p>
+(<a href="#escalation-step-4.b">step 4.b</a>).</p>
 
 <p>During the discussion period, and at all stages in the process, the
 Chairs will strive to guide the Working Group towards consensus. If
@@ -420,7 +420,7 @@
 such a Call in the first place, the chairs may proceed directly to
 <a href="#escalation-step-5b">step 5.b</a> without a Call for Consensus.</dd>
 
-<dt id="escalation-sep-4.a">4.b. Call for Alternate Proposals</dt>
+<dt id="escalation-sep-4.b">4.b. Call for Alternate Proposals</dt>
 <dd><p>When a Change Proposal has been submitted, but it's clear that
 some Working Group members would prefer a different change, or the
 status quo spec text, the Chairs issue a Call for Alternate
@@ -531,6 +531,130 @@
 submitted. <b>** This is an endpoint for the Change Proposal review process. **</b> 
 </dd>
 
+</dl>
+
+</section>
+
+<section>
+<h2 id="lc-review">Last Call and Pre-Last Call Review Process</h2>
+
+<p>Eventually, drafts become mature enough that they are ready to
+advance through the W3C Process. Given that drafts may see an ongoing
+significant influx of comments, once the draft is close, the chairs
+will establish a timetable to aid progress to the next milestone. For
+Pre-Last Call Review by the Working Group, the timetable defines the
+process to get to Last Call. For Last Call Review by the broader
+public, the timetable defines the process to enter Last Call and then
+progress to the next milestone, either Candidate Recommendation or
+another Last Call.</p>
+
+<p>The steps for a Last Call or Pre-Last Call Review are as follows:</p>
+
+
+<dl>
+
+<dt id="lc-review-step-1">1. Review Period is Defined</dt>
+<dd>
+The Chairs, in consultation with the Working Group, define the the
+time and duration of the review period. For a Pre-Last Call Review,
+this is the deadline to enter comments that will be considered before
+Last Call. For a Last Call Review, this is the Last Call Review Period
+as defined by the W3C Process.
+</dd>
+
+<dt id="lc-review-step-2">2. Review Period Begins</dt>
+<dd>
+At this point, the Working Group issues a solicitation for review
+comments. Review comments are to be submitted in bugzilla, per
+the <a href="#basic">Basic Process</a>.
+</dd>
+
+<dt id="lc-review-step-3">3. Review Period Ends</dt>
+<dd>
+The end of the review period is the cutoff for bugs to be considered
+as Last Call or Pre-Last Call feedback. Bugs beyond this date will NOT
+be treated as pre-LC or LC comments (whichever is relevant). 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. Any such bugs will be considered during a
+subsequent Last Call, during the Candidate Recommendation phase, or
+for a future version of HTML.
+</dd>
+
+<dt id="lc-review-step-4">4. Editors Complete Initial Pesponses</dt>
+<dd>Within two months of the end of the comment period, or a different
+period as determined by the Chairs in consultation with the Editors
+and the Working Group, all bugs submitted by the end of that review
+period must be given an <a href="#basic-step-2">Editor's Response</a>
+per the Basic Process. Bugs still open past this date can be escalated
+to issues immediately if the originator so
+chooses. The <a href="#escalation">Escalation Process</a> then takes
+effect.
+</dd>
+
+<dt id="lc-review-step-5">5. Deadline for Escalating Comments</dt>
+<dd>Within two weeks of the editor's response deadline, or a different
+period as determined by the Chairs in consultation with the Editors
+and the Working Group, all bugs from the review period must
+be <a href="basic-step-5d">Escalted to Issues</a> if the commentor or
+any other WG member is dissatisfied with the Editor's Response. Any
+further escalations beoyond this date will not be treated as a Last
+Call or pre-Last Call comment (whichever is applicable). Such
+escalations can be taken up during a subsequent LC or CR period.
+</dd>
+
+<dt id="lc-review-step-6">6. Calls for Change Proposals Complete</dt>
+<dd>Within four weeks of the escalation deadline, or a different
+period as determined by the Chairs in consultation with the Editors
+and the Working Group, all <a href="#escalation-step-1">Calls for
+Change Proposals</a> will be complete. Any issue that does not have a
+Change Proposal by this date will be closed without prejudice and
+marked POSTPONED. Such issuescan be reconsidered during a subsequent
+LC, CR, or for a later version of HTML.
+</dd>
+
+<dt id="lc-review-step-7">7. Calls for Alternate Proposals Complete</dt>
+<dd>
+<dd>Within four weeks of the escalation deadline, or a different
+period as determined by the Chairs in consultation with the Editors
+and the Working Group, all <a href="#escalation-sep-4.b">Calls for
+Alternate Proposals</a> will be complete. Any issue that has onlyone
+Change Proposal by this date will be resolved by Call for Consensus.
+</dd>
+
+
+<dt id="lc-review-step-8">8. All Issues Resolved</dt>
+<dd>
+Within six weeks of the end of the Calls for Alternate Proposals, all
+issues are to be resolved. The <a href="#escalation">Escalation
+Process</a> will be complete. If this date is not met, this would be
+solely a failure by the Chairs, so the Chairs would publicly eat crow
+and plot a new date.
+</dd>
+
+<dt id="lc-review-step-9">9. Working Group Resolution</dt>
+<dd>
+<p>Once all bugs and issues from the review period are addressed, and a
+reasonable amount of time has passed to verify that decisions are
+applied, the Chairs will present a resolution to the group in the form
+of a survey.</p>
+
+<p>If the Working Group approves moving to the next milestone, then
+the specification will proceed to Last Call, to a subsequent Last
+Call, or to Candidate Recommendation. In general, a specification must
+have another Last Call if substantive changes were made since the
+previous Last Call.</p>
+
+<p>If the resolution is not approved, then attempts will be made to
+address resolvable objections. If that cannot be done quickly, then
+the specification is returned to Working Draft for further work. If a
+specification repeatedly fails to advance, then the Chairs may survey
+the WG to determine whether the WG should cease work and publish the
+document as a Working Group Note instead.
+</dd>
+
+</dl>
+
 </section>
 
 </article>

Received on Monday, 16 May 2011 04:36:28 UTC