- From: Sam Ruby via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 13 Aug 2012 16:42:48 +0000
- To: public-html-commits@w3.org
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