HTML Working Group Decision Policy

1. Introduction

For products of the HTML Working Group, particularly HTML5, we expect a high volume of Last Call comments. We expect most comments can be resolved in a satisfactory way by the Editor of the affected draft. However, there are a few reasons we need to formalize our process a little bit. First, we are required by W3C Process to track and formally respond to all Last Call comments, and to produce a disposition of comments document in order to exit Last Call. Second, some commenters may not be satisfied by how their Last Call or pre-Last Call comment is initially proceed by the Editor, and the commentwill need to be resolved by a decision of the Working Group. Third, it needs to be very clear to commenters how to get their input formally considered.

Non-members are encouraged to join the Working Group so they can fully participate in this process. But extenuating circumstances for not joining the group will be considered by the Chairs on a case-by-case basis.

2. Policies Defined in this Document

This document defines a number of policies in use by the HTML Working Group. Here is a brief description of each.

3. Overview of Comment Processing

The way we will make decisions involves two subprocesses: the Basic Process and the Escalation Process. The Basic Process works primarily through Bugzilla; we believe most comments on drafts can be addressed this way, without the need to involve the full Working Group. For some comments though, the input of the full Working Group will be needed. Throughout these processes, we will rely on three types of entities to make progress. Some of these will require a Working Group member to do some work. These processes will be applied to each separate specification individually. In addition, Change Proposals that are submitted as part of the Escalation Process are reviewed in accordance with the Change Proposal Review Process.

4. Basic Process

The Basic Process describes the overall handling of a comment; we believe most steps can be handled without close involvement of the Chairs or the Working Group as a whole. We expect most comments will be disposed reasonably by the Editor of the relevant spec. For issues that need full Working Group consideration, this process refers to the Escalation Process.

Flowchart illustrating the process described below.
(SVG version)

0. (Optional) Email
Comments can be brought up initially by email, if discussion is needed before the problem is clear enough to file a bug. Commenters may go directly to the next step if they are very clear on their issue already.
1. Bugzilla Bug

Comments should be filed as bugs in W3C Bugzilla to be formally considered. If the commenter has difficulties filing a bug, the best approach is to email the comment to, and one of the Chairs or a volunteer will assist them. Bugs will be initially assigned to the Editor of the relevant draft. Although Editors may field comments through other forums if they wish, we will require Editors to address all Bugzilla bugs. We need bugs to be in Bugzilla to ensure that nothing is dropped on the floor, and to be able to produce the disposition of comments directly from the bug Tracker. A bug report is most useful if it includes the following components:

  • A clear statement of a problem with the spec—bug reports are more useful if they identify concrete problems.
  • Only one specific problem—please use separate bugs for separate problems with the spec.
  • An indication of what section or sections of the spec are affected.
  • At least one suggested way to solve the problem. Optionally, this can include sample spec text. Listing multiple alternatives is ok, and even a vague suggestion is fine at this stage.

Note: These components are not absolutely mandatory for all bug reports. But bug reports that do not have enough information to identify a problem or potential action may be closed as NEEDSINFO.

2. Editor's Response

Editors will give an initial disposition to incoming bugs. When an Editor gives the initial Editor's response, he or she should include the following:

  • A change in bug status to RESOLVED.
  • A clear statement of whether the comment was accepted or rejected.
  • A rationale for the change or lack of change (at least enough for the Disposition of Comments).
  • A link to the relevant spec diff or diffs, if the spec was changed.
  • Boilerplate text advising the commenter how to indicate their reply and escalate if desired. The following boilerplate text is suggested:

    EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
    satisfied with this response, please change the state of this bug to CLOSED. If
    you have additional information and would like the Editor to reconsider, please
    reopen this bug. If you would like to escalate the issue to the full HTML
    Working Group, please add the TrackerRequest keyword to this bug, and suggest
    title and text for the Tracker Issue; or you may create a Tracker Issue
    yourself, if you are able to do so. For more details, see this document: Status: (Accepted|Partially Accepted|Rejected|Additional Information Needed) Change Description: (description of spec change if any) Rationale: (rationale)

    For any responses that involve a spec change a link to the relevant spec diffs should also be provied.

For some particular bug resolutions, a full Editor's Response is not necessary, and it may be appropriate for someone other than the Editor of the relevant draft to resolve the bug. The table below documents the bug resolutions, and expectations for each:

FIXEDAccepted or partially accepted. Spec was changed. Editor's Resolution and diff link are required. Rationale should explain the reason for accepting the comment. It may simply cite agreement with arguments in a previous bug comment.
WORKSFORMEAccepted, but no spec change. The spec already addresses the comment due to a previous change. Editor's response required, but the rationale just needs to point to the previous change or existing spec text that addresses the comment. A resolution may be entered by someone other than the Editor if they can explain why the spec already addresses the comment.
NEEDSINFOAdditional information is required to accept or reject this comment. Editor's response required. Editor should be clear on what additional info is required. It is strongly recommended that bug reporters should provide the requested additional information, if the request is reasonable, before they consider escalating.
WONTFIXRejected. Editor's response required. Rationale should explain why the comment was rejected.
LATERRejected, but may be reconsidered for a future version. Editor's response required. Rationale should explain why this request is better handled in a future version.
REMINDDo not use this resolution.
INVALIDBug is obvious junk or spam. Or, originator decides upon reconsideration that the comment is wrong. Does not require a full Editor's response.
DUPLICATEBug is reporting the same problem as another bug. Does not require a full Editor's response.
3. Verify Response Info
Once bugs are RESOLVED, we will ask volunteers, including Team Contacts, to make sure they include all of the needed components of an Editor's response, and to add any that are missing. Once this is done, the bug should move to the VERIFIED state.
4. Commenter Satisfied?
At this point in the process, the commenter should review the Editor's response, and choose one of the following Step 5 actions. The commenter has two weeks to take action from the time the bug is put in VERIFIED state.
5.a. Yes: Close Bug
If the commenter is satisfied with the Editor's response, the commenter should indicate that by changing the bug state to CLOSED. ** This is an endpoint for the process. **
5.b. (No Response)
If the commenter never responds in the bug in any way, after two weeks the WG will assume no response is forthcoming, and indicate that in disposition of comments. At this point the bug will be tagged with the NoReply keyword, and the state will be changed to CLOSED. ** This is an endpoint for the process. **
5.c. Want Reconsideration: Reopen Bug
If the commenter feels they have new information or arguments, or that the Editor overlooked something, and would like the Editor to reconsider, it's ok to move the bug to the REOPENED state. Commenters should exercise reasonable judgment on whether to use this option or 5.d., in particular, it's usually not a good idea to repeatedly reopen the same bug. Note: A bug may be reopened by anyone who is dissatisfied with the resolution, not just the original commenter. Once reopened, the comment returns to step 1.
5.d. No: Escalate to Issue

If the commenter is dissatisfied with the resolution and does not believe it is productive to ask the Editor to reconsider, he or she may ask to escalate the comment to the issue Tracker. A commenter with Tracker access can raise an Issue directly. A commentor without Tracker access should apply the TrackerRequest keyword, and should suggest a title and text for the Tracker Issue. Team contacts or other volunteers with access will move TrackerRequest bugs into the Tracker. Note: A bug may be escalated by anyone who is dissatisfied with the resolution, not just the original commenter.

The Tracker Issue should reference the original Bugzilla bug. The Bugzilla bug will reference the issue and have the TrackerIssue keyword added.

Note: comments with additional information may still be added to a Bugzilla bug after it has been escalated to the Tracker.

Clarification:It's not correct per this policy to both escalate a bug to the Tracker and reopen it. Only one of these two actions should be taken. Reopen the bug if you would like the Editor to give it fresh consideration; escalate it if you'd like to move beyond the Editor's response and get consideration from the full Working Group.

5.e. No, But Willing to Concede: Close Bug and mark Disagree
If the commenter is unsatisfied with the Editor's response, but does not wish to pursue the comment further by escalating or reopeneing, the commenter should indicate that by changing the bug state to CLOSED and add the Disagree keyword. ** This is an endpoint for the process. **
6. Working Group Decision
Issues escalated to the Tracker will be decided by Working Group Decision. The Escalation Process describes how Working Group decisions are made.
7.a. Affirm Editor's Response
The Working Group Decision that results from the Escalation Process may be to affirm the Editor's response. In this case proceed to step 8.
7.b. Overrule Editor's Response
The Working Group Decision that results from the Escalation Process may be to overrule the Editor's response. In this case proceed to step 10.
8. Does Commenter Wish to Formally Object?
The commenter should decide at this point if they wish to enter a Formal Objection against the Working Group decision.
9.a. Formal Objection
If the commenter does wish to enter a Formal Objection, he or she should do so according to W3C Process. This includes explicitly stating that it is a Formal Objection, as well as giving a technical justification for the objection, and at least one way the objection could be removed. The Formal Objection should be recorded in the Bugzilla bug, and the bug should be placed in the CLOSED state and tagged with the FormalObjection keyword. ** This is an endpoint for the process. **
9.b. Ordinary Disagreement
If the commenter does not wish to enter a Formal Objection, then the resolution will simply be indicated as a disagreement on the Disposition of Comments. The bug should be placed in the CLOSED state and marked with the Disagree keyword. ** This is an endpoint for the process. **
10. Tag Bug as WG Decision and Reopen
The bug is reopened indicating the WG decision, and tagged with the WGDecision keyword. The bug is then returned to REOPENED state for action by the Editor to implement the Working Group decision, which will be recorded in the form of a Change Proposal. The process returns to step 1. Working Group Decisions must be applied within one calendar week of the bug being reopened. If for any reason a decision cannot be applied within the required time frame, the relevant spec's Editors must notify the Chairs and ask for an extension.

The following table summarizes what different bug states and keywords say about where a bug stands in the process. All the conditions marked with an asterisk (*) are ones we must drive to zero to finish review of Last Call comments.

State and Keywords Meaning
UNCONFIRMED, NEW, ASSIGNED, REOPENED Waiting for Editor response.*
REOPENED and WGDecision Waiting for Editor to implement Working Group decision.*
RESOLVEDEditor has addressed comment, waiting for review by verifier.*
VERIFIED (and none of the below)Waiting for response from commenter.*
VERIFIED and TrackerRequestReporter requested escalated to Working Group. Waiting for mechanics of escalation.*
VERIFIED and TrackerIssueReporter escalated to Working Group. Waiting for Working Group decision.*
CLOSED and NoReplyReporter has not responded after two weeks or more.
CLOSED and FormalObjectionThe Tracker Issue is settled, and reporter formally objected to WG.
CLOSED and DisagreedThe Tracker Issue is settled, and the reporter disagreed, but not as Formal Objection
CLOSED (and none of those)The Tracker Issue is settled, and the reporter agreed with the final outcome.

5. Escalation Process

Some issues cannot be settled solely through the Basic Process. In such cases, a party to the dispute will request escalation to the Issue Tracker. Once issues are in the Tracker, we will use a system of Change Proposals to come to a decision.

Flowchart illustrating the process described below.
(SVG version)

0. Amicable Resolution
At any stage of the process, the issue can be settled amicably, If spec changes are made that satisfy the person who raised the issue, or the person who raised it otherwise wishes to withdraw, and no one objects, the issue will be closed by Call for Consensus. Generally in this case no technical decision is entered, unless that seems important in particular cases. The Basic Process then proceeds from step 7a ** This is an endpoint for the escalation process. **
1. Raised Issue: Chairs Solicit Proposals

When an issue enters it starts in the RAISED state. The Chairs solicit volunteers to write Change Proposals when the issue is raised. For pre-existing issues, we will ask for volunteers in a staggered fashion to avoid flooding the group. Requests for Change Proposals will go out to the HTML WG mailing list and possibly via other channels as well. Note: it's ok for multiple people to volunteer to produce independent proposals for the same issue. If no one volunteers within a month, proceed to step 2.a. Otherwise proceed to step 2.b.

Note: information can be added to an Issue without writing a full Change Proposal by sending email to the public-html mailing list that mentions the issue number in the format ISSUE-nnn where nnn is the issue number.

2.a. Closed without Prejudice
If no one volunteers within a month of the Chairs' request, or a Change Proposal is not presented by the deadline, the Tracker Issue will be marked POSTPONED in the Tracker without prejudice and presumed deferred to the next version of HTML. In this case, we affirm the Editor's decision by default. The Basic Process then proceeds from step 7a. An issue that is closed without prejudice in this way can only be re-raised with approval of the Chairs. ** This is an endpoint for the escalation process. **
2.b. Open Issue: Writing a Change Proposal
An issue with someone working on a change proposal is in the OPEN state. If the change proposal is not done by the deadline, the issue will be marked POSTPONED in the Tracker without prejudice and presumed deferred to the next version of HTML. The default deadline to complete a Change Proposal is one month from the time someone volunteers. The Chairs may grant a longer deadline for complex issues on request. A proper Change Proposal must include the following four components:
  1. Summary: Describes the change in about 1-5 paragraphs of plain language.
  2. Rationale: Describes the reason for the change. What problems does the proposal address, and how does the proposal makes things better? The rationale should present technical arguments. Starting with Last Call, Change Proposals that argue against adding a feature may cite "too late to add features" as a technical argument, though such an argument is not necessarily decisive in itself.
  3. Proposal Details: This may take one of the following four forms:
    • A set of edit instructions, specific enough that they can be applied without ambiguity.
    • Spec text for a draft to be published separate from HTML5 (though such a draft can be proposed at any time without a Change Proposal).
    • Exact spec text for the sections to be changed, and a baseline revision for the version of the spec being changed.
    • With prior permission from the Chairs, a high-level prose description of the changes to be made.
  4. Impact: Effects, both positive and negative, of the change. What conformance classes will have to change? What are the risks?

Complete Change Proposals should be recorded somewhere in W3C space (wiki,, archived mailing list) and the Working Group should be notified by email. If the author of the Change Proposal is not a member of the Working Group, then he or she should agree to the W3C Patent Policy and grant a non-exclusive copyright assignment as required for invited experts.

If a Change Proposal is not complete by the deadline (default one month), proceed to step 2.a.

3. Discussion

The Change Proposal (or multiple Proposals) may be discussed and revised for a reasonable period. Authors of Change Proposals are strongly encouraged to seek consensus and revise their Change Proposals to gain more support. Change Proposals that do not see wide support are unlikely to succeed. Once an outcome is clear or no more productive discussion is happening, the Chairs proceed to the next step. If consensus on a proposal is clear, the Chairs may issue a Call for Consensus (step 4.a). If there are obvious objections or other alternatives, the Chairs may instead issue a Call for Alternate Proposals (step 4.b).

During the discussion period, and at all stages in the process, the Chairs will strive to guide the Working Group towards consensus. If amicable resolution is likely, the Chairs may mediate discussion to help find compromise proposals or middle ground solutions. Amicable resolution is the preferred outcome for any given issue, if at all possible.

Note: Editors may make changes that impact an issue under discussion, but that the Editor is expected to identify on the mailing list any changes that may affect submitted Change Proposals. If there is an issue but no pending Change Proposal, then the Editor is encouraged but not required to identify changes that may affect the issue. In the case of some issues, it may be difficult to even identify what changes would affect it without seeing a Change Proposal.

4.a. Call for Consensus
If the Chairs believe it is clear that the existing spec or some available Change Proposal enjoys consensus, they issue a Call for Consensus to solicit objections. Based on the response, proceed to the appropriate substep of step 5. If there is not enough clarity to make such a Call in the first place, the Chairs may proceed directly to step 5.b without a Call for Consensus.
4.b. Call for Alternate Proposals

When a Change Proposal has been submitted, but it's clear that some Working Group members would prefer a different change, or the status quo spec text, the Chairs issue a Call for Alternate Proposals. Requests for Alternate Proposals will go out to the HTML WG mailing list and possibly via other channels as well. Note: it's ok for multiple people to to produce independent proposals for the same issue.

Alternate Change Proposals should satisfy the usual Requirements for a Change Proposal. An Alternate Change Proposal may call for no changes to the spec at all, arguing that the existing spec text is the best way to resolve the issue. In this case, the proposal should provide rationale for the spec text as it stands. However, in some cases, an issue may revolve primarily around a request to add something, such as a new feature, and other proposals justify this addition. In this situation, it may be that the only reasonable rationale may be to give reasons why that particular addition should not be made.

If no one submits an Alternate Change Proposal within a month, or if upon submission consensus is clear, proceed to step 4.a. Otherwise proceed to step 5.b.

5.a. Consensus Found
If there are no objections, very few (and weak) objections, or objections can be resolved, the Chairs declare that the Call for Consensus becomes a resolution. The Working Group affirms or overrules the Editor's decision depending on the outcome. When reviewing the results of a survey, the Chairs will examine the Change Proposals, the survey responses themselves, and any material linked from a survey response. The Chairs do not guarantee that any other material, such as email to the WG list related to the topic, will be considered. Filtering such a volume of material is impractical. The Basic Process then proceeds from step 7a or step 7b as appropriate. ** This is an endpoint for the escalation process. **
5.b. No Clear Consensus
If there are numerous and/or serious objections, or if it is unclear to the Chairs what the position of the Working Group is, the Chairs may use a poll to get a sense of the Working Group.
6. Poll or Vote
A WG decision may be entered based on an informative straw poll as one piece of input, or based on a formal and binding vote. Or the Chairs can ask for a new round of proposals if the poll does not reveal a strongly preferred position; in this case, return to step 3. Otherwise, the Working Group affirms or overrules the Editor's decision depending on the outcome. In that case, the Chairs will strive to identify the proposal that draws the weakest objections, taking under consideration objections raised in the straw poll, reasoning in the Change Proposals themselves, and other sources of information. The Basic Process then proceeds from step 7a or step 7b as appropriate. ** This is an endpoint for the escalation process. **

6. Change Proposal Review Process

The Change Proposal Review Process describes how the Chairs review Change Proposals to ensure that they meet the basic requirements to be considered - that they include all the required parts, have proper rationale, and so forth. Change Proposals may be considered withdrawn if they do not meet requirements and are not suitably updated.

Flowchart illustrating the process described below.
(SVG version)

1. Chairs Review Proposal
Chairs will review each incoming Change Proposal or Alternate Change Proposal to ensure that it meets the requirements for a Change Proposal. In particular, Chairs will verify that all required parts are present, and that there is some form of rationale for each change present. Proceed to the appropriate substep of step 2 depending on whether the proposal meets requirements.
2.a. Proposal Meets Reqirements
If the proposal is found to meet requirements, the Escalation Process proceeds with this Change Proposal still under consideration. ** This is an endpoint for the Change Proposal review process. **
2.b. Chairs Request Update
If the Change Proposal does not fully meet requirements, the Chairs will request an update, with an indication of the specific changes needed. The Chairs may set a firm deadline if no update is forthcoming. If a revised Change Proposal is submitted, return to step 1. If none is submitted by the deadline, or the Change Proposal author indicates an uwillingness to update, proceed to step 3.
3. Proposal Considered Withdrawn
If a Change Proposal author is unable or unwilling to submit a revised Change Proposal to meet requirements by the deadline, then the Change Proposal will be considered withdrawn. The Escalation Process continues, as if this particular Change Proposal had not been submitted. ** This is an endpoint for the Change Proposal review process. **

7. First Last Call and Pre-Last Call Review Process

Eventually, drafts become mature enough that they are ready to advance through the W3C Process. Given that drafts may see an ongoing significant influx of comments, once the draft is close, the Chairs will establish a timetable to aid progress to the next milestone. For Pre-Last Call Review by the Working Group, the timetable defines the process to get to Last Call. For Last Call Review by the broader public, the timetable defines the process to enter Last Call and then progress to the next milestone, either Candidate Recommendation or another Last Call.

The steps for a Last Call or Pre-Last Call Review are as follows:

1. Review Period is Defined
The Chairs, in consultation with the Working Group, define the the time and duration of the review period. For a Pre-Last Call Review, this is the deadline to enter comments that will be considered before Last Call. For a Last Call Review, this is the Last Call Review Period as defined by the W3C Process.
2. Review Period Begins
At this point, the Working Group issues a solicitation for review comments. Review comments are to be submitted in Bugzilla, per the Basic Process.
3. Review Period Ends
The end of the review period is the cutoff for bugs to be considered as Last Call or Pre-Last Call feedback. Bugs beyond this date will NOT be treated as pre-LC or LC comments (whichever is relevant). The Chairs could grant exceptions on a case-by-case basis, but in general there is no guarantee of a bug filed after the cutoff being settled during the Last Call period. Any such bugs will be considered during a subsequent Last Call, during the Candidate Recommendation phase, or for a future version of HTML.
4. Editors Complete Initial Responses
Within two months of the end of the comment period, or a different period as determined by the Chairs in consultation with the Editors and the Working Group, all bugs submitted by the end of that review period must be given an Editor's Response per the Basic Process. Bugs still open past this date can be escalated to issues immediately if the originator so chooses. The Escalation Process then takes effect.
5. Deadline for Escalating Comments
Within two weeks of the Editor's response deadline, or a different period as determined by the Chairs in consultation with the Editors and the Working Group, all bugs from the review period must be Escalated to Issues if the commentor or any other WG member is dissatisfied with the Editor's Response. Any further escalations beyond this date will not be treated as a Last Call or pre-Last Call comment (whichever is applicable). Such escalations can be taken up during a subsequent LC or CR period.
6. Calls for Change Proposals Complete
Within four weeks of the escalation deadline, or a different period as determined by the Chairs in consultation with the Editors and the Working Group, all Calls for Change Proposals will be complete. Any issue that does not have a Change Proposal by this date will be closed without prejudice and marked POSTPONED. Such issues can be reconsidered during a subsequent LC, CR, or for a later version of HTML.
7. Calls for Alternate Proposals Complete
Within four weeks of the escalation deadline, or a different period as determined by the Chairs in consultation with the Editors and the Working Group, all Calls for Alternate Proposals will be complete. Any issue that has onlyone Change Proposal by this date will be resolved by Call for Consensus.
8. All Issues Resolved
Within six weeks of the end of the Calls for Alternate Proposals, all issues are to be resolved. The Escalation Process will be complete. If this date is not met, this would be solely a failure by the Chairs, so the Chairs would publicly eat crow and plot a new date.
9. Working Group Resolution

Once all bugs and issues from the review period are addressed, and a reasonable amount of time has passed to verify that decisions are applied, the Chairs will present a resolution to the group in the form of a survey.

If the Working Group approves moving to the next milestone, then the specification will proceed to Last Call, to a subsequent Last Call, or to Candidate Recommendation. In general, a specification must have another Last Call if substantive changes were made since the previous Last Call.

If the resolution is not approved, then attempts will be made to address resolvable objections. If that cannot be done quickly, then the specification is returned to Working Draft for further work. If a specification repeatedly fails to advance, then the Chairs may survey the WG to determine whether the WG should cease work and publish the document as a Working Group Note instead.

8. Candidate Recommendation Process Additions

Once the first set of comments have been processed, focus turns to stabilizing the specification.

1. Require bugs for every change

Starting with second and later Last Calls, the rate of change should slow significantly. At this point, we require that every change must be in response to a bug filed by the relevant Last Call deadline. This is necessary to achieve stability.

2. Limit scope of bugs to changes

For second and subsequent Last Calls, only comments related to changes made since the start of the previous Last Call will be accepted. This is to ensure we do not get into an infinite regress of new feedback; only new changes will get re-reviewed.

All bugs entered outside of this scope are to be reassigned to components set up for "" activities.

In rare cases, editors may select individual bugs, ensure that there is a proposed change, and submit such for approval to the Working Group.

3. Review then Commit

Whereas the Enhanced Change Control process merely encouraged changes to be pre-flighted with the group, at this point in the process every commit that makes a substantive change or introduces additional willful violations of other standards -- even in non-normative text, like examples -- must be pre-approved by the WG as a whole before being applied. Approvals will take place on the public html mailing list, can be done in batches by simply enumerating the bug report numbers. Ideally, such bug reports will already have proposed fixes in the form of patches linked to the bug before an approval request is made, but at a minimum any such bugs submitted for approval will have a proposed solution described in prose in sufficient detail for the Working Group to make a determination as to whether or not to allow the spec to be changed in this manner.

At least one week must be provided for approvals, and additional time should be provided should this period span a major holiday. Objections are to also be made on the public-html mailing list. If no objections are raised during that period, the change can go in.

If an objection is raised during that period, the editors are encouraged to work with the Working Group to resolve the objections. If this completes successfully, another approval request may be made.

If consensus can't be reached, the chairs will determine whether to allow the change proceed or not. Either way, this can be escalated through the normal channels by those who wish to (re)instate or revert the change. Effectively, this parallels the What happens after a revert? process.

9. Requests for a Decision to be Reopened Based on New Information

Occasionally, after a Working Group Decision is rendered, a WG Member may identify new information relevant to the decision which, per the W3C Process, could lead to the decision being reopened.

The following are the steps to request reopening :

1. Submit a Reopen Request

A request to reopen an issue should be submitted to the mailing list. A request to reopen should identify the issue to be reopened, and should include the following:

  • Material new information relevant to the decision, for example of the type identified by the decision itself as relevant.
  • A revised Change Proposal incorporating the new information as rationale.

For reopening to be seriously considered, this new information and proposal must be likely to have been enough to materially change the decision, lacking refutation or additional new information,

2. Mailing List Discussion

Working Group members discuss the proferred new information, and have the opportunity to provide refutation or counter-arguments.

3. Chairs Decide

Per the W3C Process, it is up to the Chairs to decide whether to reopen. The Chairs will apply the standard cited above. The issue will only be reopened if the new information and proposal would likely have been enough to materially change the decision, if not refuted. If the Chairs decline to reopen the issue the process ends here, else proceed to step 4.

4. Issue is Reopened

If the Chairs decide to reopen the issue, then the issue is moved back to OPEN state. The escalation process proceeds from Call for Alternate Proposals (step 4.b). Note: a reopened issue may no longer qualify to be considered during a currently running Pre-LC or LC review period and may instead be taken up in the next milestone.

10. Enhanced Change Control

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 during a pre-LC review period. Likewise, the W3C Last Call process itself imposses a cutoff on the Last Call period.

During pre-LC review periods, and first Last Calls, we don't want to call a total stop to useful changes that aren't in response to 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.

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.

New Features

Furthermore, as we move through W3C maturity levels, the process requires gradually locking down the spec. In particular:

Given these rules, it seems wise to be careful about anything that is even arguably a feature addition - even arguably ambiguous cases such as documenting longstanding de facto standard features.

Therefore during a pre-LC review, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug, a WG decision, or an on-list discussion. This applies only to LC-track drafts and does not apply to drafts that may include material for future versions of HTML.

After the start of Last Call (and through subsequent Last Calls) features can only be added to or removed from the specification with prior concurrence of the Working Group, in one of the following forms:

  1. A Working Group Decision to adopt a Change Proposal for a tracker issue, via a survey decision.
  2. A Working Group Decision to adopt a Change Proposal for a tracker issue, via a Call for Consensus.

What kind of changes might this revert policy apply to?

What happens after a revert?

11. Note Track and Recommendation Track

Whether a Working Draft eventually becomes a WG Note or proceeds down the REC track is a decision of the Working Group. The following Process defines how this can be decided.

1. Editor's Initial Decision
Initial choice of whether a draft is REC-track or Note-track is up to the Editor or Editors of that draft. Ideally Editors or Editorial teams should make their intent clear in the draft.
2. Bug Report
If any WG member disagrees with the Editor's initial decision and would like to move a draft from REC-track to Note-track or vice versa, the first step is to file a bug.
3. Editor's Response
The Editor of the relevant specification should give an Editor's Response to the request.
4. Opportunity to Escalate
If one objects to the Editor's Response, the matter is settled. If anyone does object, they should escalate to a Tracker Issue, which will be resolved by a special fast-track process; see step 5.a.
5.a. Fast Track Escalation - Call for Rationale Statements
We do not ask for full Change Proposals, merely for a rationale statement from advocates of both REC-track and Note-track. These can be brief. They can quote existing bug comments. The timeline to deliver is a month.
5.b. Fast Track Escalation - Closing without Predjudice
If neither side provides rationale, the issue is closed without prejudice and can be reopened if someone does provide rationale.
5.c. Fast Track Escalation - Call for Consensus
If only one side provides rationale, we hold a CfC to close the issue without prejudice. It can be reopened if rationale is provided later and the relevant draft has not yet gone to CR.
5.d. Fast Track Escalation - Preference Survey
If both sides provide rationale, we hold a survey. Since this is a process, not a technical decision, the survey is by individual not organization. Subject to quorum requirements, majority wins. If we do not achieve quorum, the Chairs will decide whether to re-run the survey or table the issue.

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 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 Group specification, 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. The name and URL of the base specification it is to be integrated into.
  3. Rationale for integration.
  4. Evidence showing that the extension specification satisfies the CR exit criteria for the base specification.
  5. 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 integration into a future version using the usual process.
5. Integration
As with any other working group decision, editors will apply integration decisions within a week.

13. Removing some at-risk features early in CR

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.

1. Marking as at risk
To be eligible to be removed early, the feature must be approved by the Working Group to be on the list of at-risk features prior to CR.
2. Nominating for early removal.
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 minimum 3 months after entering CR. The CfC for entering CR will identify the actual period on a specification by specification basis.
3. Chair review
Chairs will review nominations to ensure that requests for early removal are reasonable. Chairs will approve or disapprove requests within one week of the nomination.
4. Opportunity to present an implementation or tests
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.
5. Early removal
If no one presents a thorough test suite or a reasonably complete implementation by the date identified by 3 months from the date of the request, then such features will be removed early. Such features may still be pursued in standalone specifications, and may be reintegrated into the specification if they meet the CR exit criteria and have WG consensus.