W3C home > Mailing lists > Public > public-html-commits@w3.org > June 2011

html5/decision-policy decision-policy-v2.html,1.33,1.34

From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
Date: Mon, 27 Jun 2011 10:03:02 +0000
To: public-html-commits@w3.org
Message-Id: <E1Qb8ek-00053G-PJ@lionel-hutz.w3.org>
Update of /sources/public/html5/decision-policy
In directory hutz:/tmp/cvs-serv19397

Modified Files:
Log Message:
Define process for deciding whether a draft is REC-track or Note-track

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>
@@ -934,6 +935,60 @@
+<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>
+<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.
Received on Monday, 27 June 2011 10:03:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:10:42 UTC