html5/decision-policy decision-policy-v3.html,1.4,1.5

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

Modified Files:
	decision-policy-v3.html 
Log Message:
Apply patches for

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18997
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18998



Index: decision-policy-v3.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v3.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- decision-policy-v3.html	20 Aug 2012 02:07:21 -0000	1.4
+++ decision-policy-v3.html	25 Sep 2012 16:03:41 -0000	1.5
@@ -71,6 +71,10 @@
 <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>
 
+<li><a href="#cr-integration">12. Integration of Extensions during CR</a> - The Process by which the Working Group decides whether a specification that extends HTML be integrated into the core HTML spec.</li>
+
+<li><a href="#cr-remove-early">13. Removing some at-risk features early in CR</a> - The Process by which the Working Group may drop certain at-risk features early in CR..</li>
+
 </ul>
 
 
@@ -1082,6 +1086,109 @@
 
 </section>
 
+<section>
+<h2 id="cr-integration">12. Integration of Extensions during CR</h2>
+
+<p>Extensions to any of the Working Groups deliverables may proceed as
+separate extension specifications. At times, such extension
+specifications may advance more rapidly than the spec they extend (for
+example, extensions to the HTML spec itself may advance more
+rapidly). In some such cases, it may be desirable to integrate the
+extension back into the core specification.</p>
+
+<dl>
+<dt>1. Publish a First Public Working Draft of the extension spec</dt>
+<dd>To be eligible for integration, an extension specification must
+be created in the first place, and must reach at least First Public
+Working Draft maturity level.</dd>
+
+<dt>2. Satisfy CR exit criteria of the base spec</dt>
+<dd>If an extension specification is to be nominated for integration
+into a base specification, it must first meet the CR exit criteria for
+the base specification. That is, every feature in the extension spec
+must demonstrate the level of interoperability that would be required
+for a feature in the base spec.</dd>
+
+<dt>3. Nominate by the deadline</dt>
+<dd>On entry to CR of any Working Groupspecification, the Chairs
+will identify a deadline prior to the end of CR for integration of
+extensions. A Working Group member may enter a nomination for
+integration at any time prior to the deadline. A nomination for
+integration must include:
+<ol>
+<li>The name and URL of the extension specification to be integrated.</li>
+<li>The name and URL of the base specification it is to be integrated into.</li>
+<li>Rationale for integration.</li>
+<li>Evidence showing that the extension specification satisfies the CR
+exit criteria for the base specification.</li>
+<li>Instructions for textual integration for the editors of the base
+spec. These need not be detailed, but editors of the base
+specification may ask for more detail if required.</li>
+</ol>
+</dt>
+
+<dt>4. Call for Consensus</dt>
+<dd>If a Working Group member enters a nomination by the deadline,
+and it contains all of the above required elements, the chairs will
+put out a Call for Consensus. If the Call for Consensus passes, then
+editors of the base specification will integrate the extension
+according to instructions. If objections are raised, objectors should
+cite rationale, and are encouraged to identify ways in which their
+objection may be addressed. If there are objections which cite
+rationale and are not resolved in a satisfactory manner, the Call for
+Consensus fails, and the extension will not be integrated. It may
+still be proposed for a future version using the usual issue
+process.</dd>
+
+<dt>5. Integration</dt>
+<dd>As with any other working group decision, editors will apply
+integration decisions within a week.</dd>
+
+</dl>
+
+</section>
+
+<section>
+<h2 id="cr-remove-early">13. Removing some at-risk features early in CR</h2>
+
+<p>Working Group members may request early removal of features that
+the WG has approved to be on the list of at-risk features for a
+specification in (or soon to be in) Candidate Recommendation.</p>
+
+<dl>
+
+<dt>1. Marking as at risk</dt>
+<dd>To be eligible to be dropped early, the feature must be approved
+by the Working Group to be on the list of at-risk features prior to
+CR.</dd>
+
+<dt>2. Nominating for early removal.</dt>
+<dd>If an at-risk feature does not have a thorough test
+suite, and also does not have even a single reasonably complete
+implementation, it may be nominated for early removal. Nominations
+for early removal may be entered before entering CR, or up to 3 months
+after entering CR.</dd>
+
+<dt>3. Chair review</dt>
+<dd>Chairs will review nominations to ensure that requests for early removal are
+reasonable.</dd>
+
+<dt>4. Opportunity to present an implementation or tests</dt>
+<dd>If a nomination is reviewed and approved, advocates of the feature
+have up to 3 months from the date of the request to present a thorough
+test suite or a reasonably complete implementation.</dd>
+
+<dt>5. Early removal</dt>
+<dd>If no one presents a thorough test suite or
+a reasonably complete implementation by the date 3 months after the
+request is made, then such features will be removed early. Such
+features may still be pursued in standalone specifications, and may be
+reintegrated into the core specification if they meet the CR exit
+criteria and have WG consensus.</dd>
+
+</section>
+
+
 </article>
 </body>
 </html>

Received on Tuesday, 25 September 2012 16:03:49 UTC