- From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 27 Jun 2011 10:03:02 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/decision-policy In directory hutz:/tmp/cvs-serv19397 Modified Files: decision-policy-v2.html Log Message: Define process for deciding whether a draft is REC-track or Note-track http://www.w3.org/Bugs/Public/show_bug.cgi?id=12776 Index: decision-policy-v2.html =================================================================== RCS file: /sources/public/html5/decision-policy/decision-policy-v2.html,v retrieving revision 1.33 retrieving revision 1.34 diff -u -d -r1.33 -r1.34 --- decision-policy-v2.html 20 Jun 2011 06:45:32 -0000 1.33 +++ decision-policy-v2.html 27 Jun 2011 10:03:00 -0000 1.34 @@ -67,6 +67,7 @@ <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> </ul> @@ -934,6 +935,60 @@ </section> +<section> +<h2 id="note-vs-rec">9. 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 +Process defines how this can be decided.</p> + +<dl> +<dt>1. Editor's Initial Decision</dt> +<dd>Initial choice of whether a draft is REC-track or Note-track is up +to the Editor or Editors of that draft. Ideally Editors or Editorial +teams should make their intent clear in the draft.</dd> + +<dt>2. Bug Report</dt> +<dd>If any WG member disagrees with the Editor's initial decision and +would like to move a draft from REC-track to Note-track or vice versa, +the first step is to <a href="#Bugzilla-bug">file a bug</a>.</dd> + +<dt>3. Editor's Response</dt> +<dd>The Editor of the relevant specification should give +an <a href="#basic-step-2">Editor's Response</a> to the request.</dd> + +<dt>4. Opportunity to Escalate</dt> +<dd>If one objects to the Editor's Response, the matter is settled. If +anyone does object, they should <a href="#basic-step-5d">escalate to a +Tracker Issue</a>, which will be resolved by a special fast-track +process; see step 5.a.</dd> + +<dt>5.a. Fast Track Escalation - Call for Rationale Statements</dt> +<dd>We do not ask for full Change Proposals, merely for a rationale +statement from advocates of both REC-track and Note-track. These can be brief. +They can quote existing bug comments. The timeline to deliver is a month.</dd> + +<dt>5.b. Fast Track Escalation - Closing without Predjudice<dt> +<dd>If neither side provides rationale, the issue is closed without +prejudice and can be reopened if someone does provide rationale.</dd> + +<dt>5.c. Fast Track Escalation - Call for Consensus</dt> +<dd>If only one side provides rationale, we hold a CfC to close the issue +without prejudice. It can be reopened if rationale is provided later and the +relevant draft has not yet gone to CR.</dd> + +<dt>5.d. Fast Track Escalation - Preference Survey</dt> +<dd>If both sides provide rationale, we hold a survey. Since this is a +process, not a technical decision, the survey is by individual not +organization. Subject to quorum requirements, majority wins. If we do +not achieve quorum, the Chairs will decide whether to re-run the +survey or table the issue. +</dd> + +</dl> + +</section> + </article> </body> </html>
Received on Monday, 27 June 2011 10:03:04 UTC