? bug-for-every-change-v2.patch.txt
? bug-for-every-change.patch.txt
? extension-integration.patch.txt
? feature-freeze-v2.patch.txt
? feature-freeze-v3.patch.txt
? feature-freeze.patch.txt
? limit-lc2-scope.patch.txt
? too-late-for-features.patch.txt
? wg-decision-deadline-v2.patch.txt
? wg-decision-deadline.patch.txt
Index: decision-policy-v3.html
===================================================================
RCS file: /sources/public/html5/decision-policy/decision-policy-v3.html,v
retrieving revision 1.4
diff -u -r1.4 decision-policy-v3.html
--- decision-policy-v3.html 20 Aug 2012 02:07:21 -0000 1.4
+++ decision-policy-v3.html 25 Sep 2012 04:59:10 -0000
@@ -71,6 +71,8 @@
10. Enhanced Change Control - The policy for enhanced change control and revert requests after specific pre-LC cutoff dates and during LC review.
11. Note Track and Recommendation Track - 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.
+12. Integration of Extensions during CR - The Process by which the Working Group decides whether a specification that extends HTML be integrated into the core HTML spec.
+
@@ -1082,6 +1084,69 @@
+
+12. Integration of Extensions during CR
+
+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.
+
+
+- 1. Publish a First Public Working Draft of the extension spec
+- 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.
+
+- 2. Satisfy CR exit criteria of the base spec
+- 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.
+
+- 3. Nominate by the deadline
+- 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:
+
+- The name and URL of the extension specification to be integrated.
+- The name and URL of the base specification it is to be integrated into.
+- Rationale for integration.
+- Evidence showing that the extension specification satisfies the CR
+exit criteria for the base specification.
+- 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.
+
+
+
+ - 4. Call for Consensus
+- 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.
+
+- 5. Integration
+- As with any other working group decision, editors will apply
+integration decisions within a week.
+
+
+
+
+
+