html5/decision-policy decision-policy-v2.html,1.26,1.27

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

Modified Files:
	decision-policy-v2.html 
Log Message:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12675
Describe enhanced change control in Decision Policy


Index: decision-policy-v2.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v2.html,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -d -r1.26 -r1.27
--- decision-policy-v2.html	30 May 2011 00:25:12 -0000	1.26
+++ decision-policy-v2.html	30 May 2011 21:08:51 -0000	1.27
@@ -51,6 +51,7 @@
 <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 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 pre-LC cutoff dates and during LC review.</li>
 
 </ul>
 
@@ -778,6 +779,97 @@
 
 </section>
 
+<section>
+<h2 id="enhanced-cc">9. 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
+high volume volume of feedback we see, it is not practical to get to 0
+bugs + 0 issues + 0 bugs closed recently enough that someone may be
+filing an issue shortly at the same time. Therefore, we impose a
+cutoff for comments to be taken as pre-LC feedback. Likewise, the W3C
+Last Call process itself imposses a cutoff on the Last Call period.</p>
+
+<p>During such periods, we don't want to call a total stop to useful
+changes that aren't in response to those bugs. But that might create a
+situation where a person or group strongly objects to some change
+after the cutoff, but they don't have automatic recourse through the
+normal bug process.</p>
+
+<p>Therefore, in exceptional cases, we would ask for a change to be
+reverted from the LC-track draft pending resolution of the issue
+through the Working Group. If any Working Group member sees a change
+go into any draft subject to a cutoff that seems controversial and
+likely to reduce rather than increase consensus, the correct step is
+to let the Chairs know, ideally via a post to the public list. The
+Chairs will make the call.</p>
+
+<h3>What kind of changes might this revert policy apply to?</h3>
+
+<ul>
+<li>We do not expect this process to be used casually over random
+changes. Snyone asking for this would have to convince the
+chairs that the change reduces consensus.</li>
+
+<li>We think there is little chance of this process being used to
+revert a fix for a UA behavior bug, because (a) that is not the sort
+of thing people complain about; and (b) divergence there would be a
+very serious problem, so everyone would be highly incentivized to seek
+other solutions. So if someone finds a late-breaking bug in the
+parsing algorithm, that's not the kind of change that would be
+problematic. We definitely want UA behavior fixes to still be on the
+table.</li>
+
+<li>Based on past experience, it seems likely that changes to
+accessibility topics already covered by issues are likely to be
+controversial. Editors may want to tread carefully in that area.</li>
+
+<li>If a change is preflighted with the group, via a bug with
+sufficient time for affected parties to comment, by posting a diff, or
+by mailing list discussion, the Chairs will be less likely to grant
+revert requests and would instead expect escalation to follow the
+normal process.</li>
+
+<li>It is also reasonably likely that this process could be used to
+object to new features. The Chairs recommend in general that new
+features should not be added after the cutoff, except in particularly
+exceptional circumstances.
+<!-- FIXME: this text needs to be expandedand clarified to cover http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=12734 -->
+</li>
+
+<li>Most likely, this process will be used for the types of changes
+that in the past have lead to such wide concern that they led to
+reverts anyway. This policy formalizes that proces for clarity of all
+in the Working Group.</li>
+
+<li>It can't be guaranteed that no revert would lead to a fork of specific
+paragraphs or sentences; but it is *highly* likely that most calls for
+a revert could be dealt with so that there is simply omitted text or
+additional text in the W3C draft relative to the WHATWG draft.</li>
+
+</ul>
+
+<h3>What happens after a revert?</h3>
+
+<ul>
+
+<li>If a spec change that gets reverted was based on a bug, the bug
+effectively goes WONTFIX.It would have to be owned by and given a
+rationale by the Chairs, since it wouldn't be the editors choice to
+revert. This bug could be escalated through the normal channels by
+those who wish to reinstate the reverted change.</li>
+
+<li>A speedy revert would not be a permanent WG decision, not even for
+Last Call; it would simply a temporary mesure to maintain the
+perception of fairness for all Working Group members and to avoid the
+feeling that there is no recourse for certain changes.</li>
+
+<!-- FIXME: Need to address http://www.w3.org/Bugs/Public/show_bug.cgi?id=11197 here -->
+
+</ul>
+
+</section>
+
 </article>
 </body>
 </html>

Received on Monday, 30 May 2011 21:08:55 UTC