Draft HTML5 Stabilization Plan

• Q1: What documents will be stabilized? #

  • Q1a: What is the exact list of documents to be stabilized? #

    • proposal: the same six documents that were in LC1
      • open question: should alt-techniques move to another venue?
    • editors are welcome to propose additions

  • Q1b: When will we create versions of the documents that will only contain LC1 resolutions and that will be taken into LC2? #

    • when there is pressure to add post-HTML5 features
    • in order to get decisions implemented
    • May 7, 2012: first documents unhooked from HTML proposal activities
      • Minimum set: HTML5 and Canvas
      • Maximum set: answer to Q1a

• Q2: Appointment of Editors for stabilized documents #

  • Q2a: When and how did we make a call for volunteers for editing the stabilized documents? #

    • HTML Working Group Changes was posted on April 23rd to the public_html mailing list.

  • Q2b: Do we need a job description for the new editors to define their roles? #

    • Q6 (DP bugs required for stabilization) captures this work in progress.
    • Input from the editors that are chosen will be needed to complete this work.

  • Q2c: When do the editors for the stabilized document take over these documents? #

    • When the editors are appointed, but no earlier than May 7th.
    • Target is May 23rd.

  • Q2d: Can editors of the stabilized documents also volunteer to work on HTML.Next proposals? #

    • Yes

  • Q2e: Can editors of the stabilized documents incorporate changes other than ones that are made to the proposals for future work? #

    • Yes, relates to Decision Policy bug 12734

  • Q2f: Will the revert policy still be in effect for stabilized documents? #

    • The chairs agree to solicit the input from the editors named before proceeding with this item.
    • Should the stable draft editors agree to no make changes that have not been pre-approved by the WG, the revert policy will no longer be necessary.

  • Q2g: How should Recommendation-track editors and HTML proposal authors work together to avoid contradictions? #

    • The authors and editors themselves should come up with an approach for working together to avoid unnecessary contradictions.
    • Recommendation-track editors will be bound by Working Group decisions and an increasingly locked down process. Conflict avoidance cannot override WG Decisions, nor can it substitute for input that was not provided directly to the WG as a whole to be considered.

• Q3: Current LC1 and late LC1 bugs #

  • Q3a: What do we do with LC1 bugs that have not been processed late in LC1? #

    • POSTPONE to HTML5.next, see also Q4b

  • Q3b: Will we need a second Last Call (LC2)? #

    • As the first Last Call announcement generated comments that resulted in substantive changes to each Last Call document, a second Last Call will be necessary. The changes proposed in this stabilization plan are intended to reduce the likelihood of this reoccurring.

  • Q3c: What do we do with bugs entered after LC1 deadline? #

    • We will reassign all unprocessed post LC1 bugs to LC2

  • Q3d: When do we create the LC2 bugzilla components? #

    • All bugs entered into the current components will be treated as LC2 bugs. At the end of LC2, we will create the LC2 bugzilla components and move all of the current bugs to those components.

  • Q3e: After what point will bugs entered in the comment forms present in the Working and Editors Drafts of Recommendation-track specifications produced by the HTML WG be considered LC2 bugs? #

    • Immediately

  • Q3f: When and how do we stop changes being made to the LC1 drafts EXCEPT for WG Decisions? #

    • See Decision Policy bug 16481.

  • Q3g: What do we do about the current timeline which was missed? #

    • The chairs plan to propose a new schedule at the May 3/4 F2F and concurrently on the public_html mailing list

• Q4: Last Call 2 planning #

  • Q4a: Will we provide a LC2 schedule like we did for LC1? #

    • Yes, with milestones.

  • Q4b: How will we lock down the scope of the kinds of comments that can be made during LC2 to only changes made during LC1? #

    • Generally LC2 Bugs that are outside of the scope of LC1 changes will be POSTPONED. See Decision Policy bug 16481 for details and how exceptions will be handled.

  • Q4c: Are we going to use Editorial assistants #

    • The chairs agree to solicit the input from the editors named before proceeding with this item.

  • Q4d: Are we going to use the PriorityRequest process? #

    • Yes

  • Q4e: How will the Candidate Recommendation Exit Criteria and Features at Risk be decided? #

    • Determining these things is a decision for the Working Group. The W3C Process defines minimum exit criteria and requires that additional criteria be defined before entering CR.
      • An example of how other WG's have handled this: CSS21

• Q5: What will the relationship be between current Recommendation Track work and work on what will come after HTML5 ("HTML.Next")? #

  • Q5a: When we announce the plan for stabilizing the W3C Last Call WDs what do we say about HTML.Next? #

    • W3C has started the process of extending the W3C HTML WG charter to jump start the work on HTML.Next in parallel to completing the current Recommendation track work. Once the HTML WG is re-chartered then the W3C will review proposals for HTML.Next work, and seek additional editors or co-editors for HTML.Next work.

  • Q5b: Where is the HTML.Next work done ie in the HTML WG or elsewhere? Who decides this? #

    • The working group needs to decide what it intends to work on.
      • Will require rechartering, and is subject to AC approval
    • Proposals that are intended to be input for future products of the HTML WG, can come from Community Groups, HTML WG Task Forces or the HTML WG itself.
      • We suggest that Proposals be modeled after the encrypted-media.html proposal.

  • Q5c: What is Ian Hickson's new role relative to HTML.Next? #

    • Ian will continue editing the WHATWG HTML specification, which we anticipate will be proposed as input for future products of the HTML WG

  • Q5d: Will this be an exclusive role? #

    • No, as before, others are welcome to make their own proposals which also will be used as input for future products of the HTML WG.

  • Q5e: Can an author of an HTML.Next proposal RESOLVE LC2 bugs which were entered against stable drafts? #

    • No. But we would be willing to create new bugzilla components for HTML.Next proposals.
      • Authors and editors should work together to work out how and when bugs should be automatically cloned into each of bugzilla components associated with the proposals that it might apply to

  • Q5f: Will the HTML Working Group Decision Policy apply to HTML.Next proposals? #

    • No. The earliest the Decision Policy could possibly apply to HTML.Next work would be once the WG decides to produce HTML.Next documents. The Decision Policy would only apply to those documents, and not to the proposals on which they may be based.

  • Q5g: Will HTML.Next be published by a Community Group? #

    • No, Community Groups do not have the ability to publish W3C Standards-track documents directly. So if by HTML.Next we mean the next numbered version of the HTML Recommendation-track standard, e.g. HTML6, it's not possible for that work to be done in a CG. The WG itself (once rechartered) will have ownership over HTML.Next.
    • What a CG can do is produce documents that can be used as input by Working Groups. Community Groups, if formed, will likely produce live documents and possibly snapshots. The HTML WG, once rechartered, may someday choose to incorporate some or all of that work, at which point it would be subject to the normal WG review process.

• Q6: What Decision Policy bugs are required for stabilization? #

  • Decision Policy bug 16481: Establish a feature freeze - no adding of new features based on bug or editor's discretion, without prior WG approval

    • Proposed diff is attached to the bug

  • Decision Policy bug 16674: Feature discouragement in issue process - can use "too late to add features" as a technical argument in a counter-proposal

    • Proposed diff is attached to the bug

  • Decision Policy bug 12734: Starting with LC2 or perhaps before, all changes need to be associated with a duly filed LC2 or earlier bug

    • Proposed diff is attached to the bug

  • Decision Policy bug 16675: Switch to a review-then-commit model for spec development

    • The chairs agree to solicit the input from the editors named before proceeding with this item.

  • Decision Policy bug 13306: Establish a deadline for implementation of WG Decisions

    • Proposed diff is attached to the bug

  • Decision Policy bug 16676: Limit scope of LC2 bugs to relate to items that were changed since LC1

    • Proposed diff is attached to the bug

  • Others? See existing Open Decision Policy bugs