html5/decision-policy decision-policy-v3.html,1.1,1.2

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

Modified Files:
	decision-policy-v3.html 
Log Message:
Apply more patches, and introduce text meant to resolve
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16675


Index: decision-policy-v3.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v3.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- decision-policy-v3.html	13 Aug 2012 15:49:20 -0000	1.1
+++ decision-policy-v3.html	13 Aug 2012 16:42:46 -0000	1.2
@@ -64,10 +64,12 @@
 Issues for consideration by the full Working Group.</li>
 
 <li><a href="#cp-review-process">6. Change Proposal Review Process</a> - The process by which Chairs review Change Proposals.</li>
-<li><a href="#lc-review">7. Last Call and Pre-Last Call Review Process</a> - The meta-process by which the Working Group drives an LC or Pre-LC Review.</li>
-<li><a href="#reopening">8. Requests for a Decision to be Reopened Based on New Information</a> - The process by which Working Group members may ask to have a decision reopened, if they believe they have relevant new information.</li>
-<li><a href="#enhanced-cc">9. Enhanced Change Control</a> - The policy for enhanced change control and revert requests after specific pre-LC cutoff dates and during LC review.</li>
-<li><a href="#note-vs-rec">10. Note Track and Recommendation Track</a> - The process by which the Working Group decides whether a Working Draft will ultimately proceed down the Recommendation track or will end up as a Working Group Note.</li>
+<li><a href="#lc-review">7. First Last Call and Pre-Last Call Review Process</a> - The meta-process by which the Working Group drives an LC or Pre-LC Review.</li>
+<li><a href="#lc2">8. Second Last Call Process Additions</h2> - additions
+intended to reduce the rate of change to the document.</li>
+<li><a href="#reopening">9. Requests for a Decision to be Reopened Based on New Information</a> - The process by which Working Group members may ask to have a decision reopened, if they believe they have relevant new information.</li>
+<li><a href="#enhanced-cc">10. Enhanced Change Control</a> - The policy for enhanced change control and revert requests after specific pre-LC cutoff dates and during LC review.</li>
+<li><a href="#note-vs-rec">11. Note Track and Recommendation Track</a> - The process by which the Working Group decides whether a Working Draft will ultimately proceed down the Recommendation track or will end up as a Working Group Note.</li>
 
 </ul>
 
@@ -339,7 +341,10 @@
 action by the Editor to implement the Working Group decision, which
 will be recorded in the form of a <a href="#change-proposal">Change
 Proposal</a>. The process returns to <a href="#basic-step-1">step
-1</a>.</dd>
+1</a>. Working Group Decisions must be applied within one calendar
+month of the bug being reopened. If for any reason a decision cannot
+be applied within the required time frame, the relevant spec's Editor
+must notify the Chairs and ask for an extension.</dd>
 </dl>
 
 <p>The following table summarizes what different bug states and
@@ -609,7 +614,7 @@
 </section>
 
 <section>
-<h2 id="lc-review">7. Last Call and Pre-Last Call Review Process</h2>
+<h2 id="lc-review">7. First 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
@@ -644,14 +649,20 @@
 
 <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
+<p>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.
+for a future version of HTML.</p>
+
+<p>For second and subsequent Last Calls, only comments related to
+changes made since the start of the previous Last Call will be
+accepted. This is to ensure we do not get into an infinite regress of
+new feedback; only new changes will get re-reviewed.</p>
+
 </dd>
 
 <dt id="lc-review-step-4">4. Editors Complete Initial Responses</dt>
@@ -731,7 +742,57 @@
 </section>
 
 <section>
-<h2 id="reopening">8. Requests for a Decision to be Reopened Based on New Information</h2>
+<h2 id="lc2">8. Second Last Call Process Additions</h2>
+
+<p>Once the first set of comments have been processed, focus turns to
+stabilizing the specification.</p>
+
+<dl>
+
+<dt id="lc2-rtc">1. Review then Commit</dt>
+<dd>
+<p>
+Whereas the <a href="#enhanced">Enhanced Change Control</a> process merely
+encouraged changes to be pre-flighted with the group, at this point in the
+process every every commit that makes a substantive change or introduces
+additional willful violations of other standards -- even in non-normative
+text, like examples -- must be pre-approved by the WG as a whole before being
+applied.  Approvals will take place on the <a
+href="http://lists.w3.org/Archives/Public/public-html/">public html</a>
+mailing list, can be done in batches by simply enumerating the bug report
+numbers.  Ideally, such bug reports will already have proposed fixes in the
+form of patches linked to the bug before an approval request is made, but at a
+minimum such any bugs submitted for approval will have a proposed solution
+described in prose in sufficient detail for the Working Group to make a
+determination as to whether or not to allow the spec to be changed in this
+manner.
+</p>
+<p>
+At least 72 hours must be provided for approvals, and additional time should
+be provided should this period span a weekend or a holiday.  Objections are to
+also be made on the public-html mailing list.  If no objections
+are raised during that period, the change can go in.
+</p>
+<p>
+If an objection is raised during that period, the editors are encouraged to
+work with the Working Group to resolve the objections.  If this completes
+successfully, another approval request may be made.
+</p>
+<p>
+If consensus can't be reached, the chairs will determine whether to allow the
+change proceed or not.  Either way, this can be escalated through the normal
+channels by those who wish to (re)instate or revert the change.  Effectively,
+this parallels the <a href="#after-revert">What happens after a revert?</a>
+process.
+</p>
+
+</dd>
+</dl>
+
+</section>
+
+<section>
+<h2 id="reopening">9. Requests for a Decision to be Reopened Based on New Information</h2>
 
 <p>Occasionally, after a Working Group Decision is rendered, a WG
 Member may identify new information relevant to the decision which,
@@ -794,7 +855,7 @@
 </section>
 
 <section>
-<h2 id="enhanced-cc">9. Enhanced Change Control</h2>
+<h2 id="enhanced-cc">10. Enhanced Change Control</h2>
 
 <p>There are certain circumstances in the Working Group where a cutoff
 date applies. For Pre-Last Call review by the Working Group, given the
@@ -922,7 +983,7 @@
 
 </ul>
 
-<h3>What happens after a revert?</h3>
+<h3 id="after-revert">What happens after a revert?</h3>
 
 <ul>
 
@@ -956,7 +1017,7 @@
 </section>
 
 <section>
-<h2 id="note-vs-rec">9. Note Track and Recommendation Track</h2>
+<h2 id="note-vs-rec">11. Note Track and Recommendation Track</h2>
 
 <p>Whether a Working Draft eventually becomes a WG Note or proceeds
 down the REC track is a decision of the Working Group. The following

Received on Monday, 13 August 2012 16:42:50 UTC