? 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: +
      +
    1. The name and URL of the extension specification to be integrated.
    2. +
    3. The name and URL of the base specification it is to be integrated into.
    4. +
    5. Rationale for integration.
    6. +
    7. Evidence showing that the extension specification satisfies the CR +exit criteria for the base specification.
    8. +
    9. 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.
    10. +
    + + +
    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.
    + +
    + + +
    +