- From: CVS User sruby <cvsmail@w3.org>
- Date: Tue, 23 Apr 2013 12:00:04 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/decision-policy
In directory roscoe:/tmp/cvs-serv11235
Modified Files:
decision-policy.html
Added Files:
decision-policy-v1.html
Log Message:
make "decision-policy.html" a cool URI
--- /sources/public/html5/decision-policy/decision-policy.html 2011/05/29 23:00:03 1.16
+++ /sources/public/html5/decision-policy/decision-policy.html 2013/04/23 12:00:04 1.17
@@ -8,51 +8,126 @@
article, section {
display: block;
margin: 0px }
-#states-and-keywords, #states-and-keywords td, #states-and-keywords th {
+#states-and-keywords, #states-and-keywords td, #states-and-keywords th,
+#bug-resolutions, #bug-resolutions td, #bug-resolutions th {
border: 2px solid black;
border-collapse: collapse }
+#toc {
+ list-style: none;
+}
+#toc > li > a {
+ font-size: 110%;
+ color: #005A9C;
+}
+
</style>
</head>
<body>
<article>
<h1>HTML Working Group Decision Policy</h1>
+<dl>
+ <dt>This Version:</dt>
+ <dd><a href="http://dev.w3.org/html5/decision-policy/decision-policy-v3.html">http://dev.w3.org/html5/decision-policy/decision-policy-v3.html</a></dd>
+<dt>Latest Published Version:</dt>
+ <dd><a href="http://dev.w3.org/html5/decision-policy/decision-policy.html">http://dev.w3.org/html5/decision-policy/decision-policy.html</a></dd>
+ <dt>Previous Versions:</dt>
+ <dd><a href="http://dev.w3.org/html5/decision-policy/decision-policy-v2.html">http://dev.w3.org/html5/decision-policy/decision-policy-v2.html</a></dd>
+ <dd><a href="http://dev.w3.org/html5/decision-policy/decision-policy-v1.html">http://dev.w3.org/html5/decision-policy/decision-policy-v1.html</a>
+</dl>
+
<section>
-<h2>Introduction</h2>
+<h2>1. Introduction</h2>
+
+<p>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.</p>
+
+<p>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.</p>
+
+</section>
+
+<section>
+<h2>2. Policies Defined in this Document</h2>
+
+<p>This document defines a number of policies in use by the HTML Working Group. Here is a brief description of each.</p>
+
+<ul id=toc>
+
+<li><a href="#overview">3. Overview of Comment Processing</a> - Summary of how to submit and track comments to the HTML WG.</li>
+<li><a href="#basic">4. Basic Process</a> - The Bugzilla-based process by which feedback is initially submitted and considered by Editors.</li>
+
+<li><a href="#escalation">5. Escalation Process</a> - The
+Tracker-based process by which commenters can escalate comments to
+Issues for consideration by the full Working Group.</li>
-<p>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 comments will not be satisfactory as initially fielded by the editor, and will 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.</p>
+<li><a href="#cp-review-process">6. Change Proposal Review Process</a> - The process by which Chairs review Change Proposals.</li>
+<li><a href="#lc-review">7. First Last Call and Pre-Last Call Review Process</a> - The meta-process by which the Working Group drives an LC or Pre-LC Review.</li>
+<li><a href="#cr">8. Candidate Recommendation Process Additions</h2> - additions
+intended to reduce the rate of change to the document.</li>
+<li><a href="#reopening">9. Requests for a Decision to be Reopened Based on New Information</a> - The process by which Working Group members may ask to have a decision reopened, if they believe they have relevant new information.</li>
+<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>
-<p>While the primary purpose of this process is for Last Call, we'd like to start on the process of migrating the Working Group over to the process right away. We've already informally been asking commenters to follow some of these steps.</p>
+<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 any HTML WG specification can be integrated into the original specification.</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 remove certain at-risk features early in CR.</li>
+
+</ul>
+
+
+</section>
+
+<section>
+<h2 id=overview>3. Overview of Comment Processing</h2>
<p>The way we will make decisions involves two subprocesses:
the <a href="#basic">Basic Process</a> and
-the <a href="#escalation">Escalation Process</a>. 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 issues though, the input of the full Working
+the <a href="#escalation">Escalation Process</a>. 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.</p>
+to each separate specification individually. In addition, Change
+Proposals that are submitted as part of the Escalation Process are
+reviewed in accordance with the <a href="cp-review-process">Change
+Proposal Review Process</a>.</p>
<ul>
<li><b>Bugzilla bugs:</b> These record a problem, and are given an
-initial disposition by the editor of the affected spec. If you want to
+initial disposition by the Editor of the affected spec. If you want to
report a problem, you should expect that you will have to file
-bugzilla bugs, or convince someone else to do so. Details
-of <a href="#bugzilla-bug">what should go in a bug</a> are explained
+Bugzilla bugs, or convince someone else to do so. Details
+of <a href="#Bugzilla-bug">what should go in a bug</a> are explained
below.</li>
-<li><b>Tracker Issues:</b> These record that an editor's resolution
+<li><b>Tracker Issues:</b> These record that an Editor's Resolution
was not satisfactory, and so the full Working Group must address the
-issue. Action items and informational updates go here. If you are
-unhappy with the way an editor addressed a bugzilla bug, you should be
-prepared to request escalation to a tracker issue.</li>
+comment. Action items and informational updates go here. If you are
+unhappy with the way an Editor addressed a Bugzilla bug, you should be
+prepared to request escalation to a Tracker Issue.</li>
<li><b>Change Proposals:</b> These documents will describe and justify
a particular proposed spec change. They are needed to make progress on
-resolving issue tracker issues. If you want to have an issue addressed
+resolving Tracker Issues. If you want to have an issue addressed
after escalation, you should expect that you will have to write a
Change Proposal, or convince someone else to do so. Details
of <a href="#change-proposal">what should go in a Change Proposal</a>
@@ -63,12 +138,12 @@
</section>
<section>
-<h2 id="basic">Basic Process</h2>
+<h2 id="basic">4. Basic Process</h2>
-<p>The Basic Process describes the overall handling of an issue; we
+<p>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
+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.</p>
@@ -77,99 +152,185 @@
<dl>
<dt>0. (Optional) Email</dt>
-<dd>Issues can be brought up initially by email, if discussion is needed before the issue is clear enough to file a bug. Commenters may go directly to the next step if they are very clear on their issue already.</dd>
+<dd>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.</dd>
<dt id="basic-step-1">1. Bugzilla Bug</dt>
-<dd><p>Issues should
+<dd><p>Comments should
be <a href="http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG">filed
as bugs in W3C Bugzilla</a> to be formally considered. If the
-commenter has difficulties filing a bug, 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 issues
-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:</p>
+commenter has difficulties filing a bug, the best approach is to email
+the comment
+to <a href="mailto:public-html-comments@w3.org">public-html-comments@w3.org</a>,
+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:</p>
-<ul id="bugzilla-bug">
+<ul id="Bugzilla-bug">
<li>A clear statement of a problem with the spec—bug reports are more useful if they identify concrete problems.</li>
- <li>Only one issue—please use separate bugs for separate issues.</li>
+ <li>Only one specific problem—please use separate bugs for separate problems with the spec.</li>
<li>An indication of what section or sections of the spec are affected.</li>
<li>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.</li>
</ul>
<p>
<b>Note:</b> 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 INVALID.
+identify a problem or potential action may be closed as NEEDSINFO.
</p>
</dd>
-<dt>2. Editor's Response</dt>
-<dd><p>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:</p>
+<dt id="basic-step-2">2. Editor's Response</dt>
+
+<dd><p>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:</p>
+
<ul>
<li>A change in bug status to RESOLVED.</li>
<li>A clear statement of whether the comment was accepted or rejected.</li>
<li>A rationale for the change or lack of change (at least enough for the Disposition of Comments).</li>
<li>A link to the relevant spec diff or diffs, if the spec was changed.</li>
-<li>Boilerplate text advising the commenter how to indicate their reply and escalate if desired.</li>
+<li><p>Boilerplate text advising the commenter how to indicate their
+reply and escalate if desired. The following boilerplate text is
+suggested:</p>
+
+<blockquote>
+<pre>
+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:</p>
+ http://dev.w3.org/html5/decision-policy/decision-policy.html
+
+Status: (Accepted|Partially Accepted|Rejected|Additional Information Needed)
+Change Description: (description of spec change if any)
+Rationale: (rationale)
+</pre>
+</blockquote>
+
+<p>For any responses that involve a spec change a link to the relevant
+spec diffs should also be provied.</p>
+</li>
</ul>
+<p>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:</p>
+
+<table id="bug-resolutions">
+<tr><th>Resolution</th><th>Description</th></tr>
+<tr><td>FIXED</td><td>Accepted 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.</td></tr>
+<tr><td>WORKSFORME</td><td>Accepted, 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.</td></tr>
+<tr><td>NEEDSINFO</td><td>Additional 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.</td></tr>
+<tr><td>WONTFIX</td><td>Rejected. Editor's response
+required. Rationale should explain why the comment was rejected.</td></tr>
+<tr><td>LATER</td><td>Rejected, 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.</td></tr>
+<tr><td>REMIND</td><td>Do not use this resolution.</td></tr>
+<tr><td>INVALID</td><td>Bug is obvious junk or spam. Or, originator
+decides upon reconsideration that the comment is wrong. Does not
+require a full Editor's response.</td></tr>
+<tr><td>DUPLICATE</td><td>Bug is reporting the same problem as another bug. Does not require a full
+Editor's response.</td></tr>
+</table>
</dd>
<dt>3. Verify Response Info</dt>
<dd>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,
+Editor's response, and to add any that are missing. Once this is done,
the bug should move to the VERIFIED state.</dd>
<dt>4. Commenter Satisfied?</dt>
-<dd> 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.</dd>
+<dd> 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.</dd>
<dt>5.a. Yes: Close Bug</dt>
-<dd>If the commenter is satisfied with the editor's response, the
+<dd>If the commenter is satisfied with the Editor's response, the
commenter should indicate that by changing the bug state to
CLOSED. <b>** This is an endpoint for the process. **</b></dd>
<dt>5.b. (No Response)</dt>
<dd>If the commenter never responds in the bug in any way, after two
-weeks will will assume no response is forthcoming, and indicate that
+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. <b>** This is an endpoint for the
-process. **</b></dd>
+the NoReply keyword, and the state will be changed to CLOSED. <b>**
+This is an endpoint for the process. **</b></dd>
<dt>5.c. Want Reconsideration: Reopen Bug</dt>
<dd>If the commenter feels they have new information or arguments, or
-that the editor overlooked something, and would like the editor to
+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. The issue then returns to <a href="#basic-step-1">step 1</a>.</dd>
-
-<dt>5.d. No: Escalate to Issue</dt>
-<dd><p>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 issue 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 issues into the tracker.</p>
+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 <a href="#basic-step-1">step 1</a>.</dd>
+
+<dt id="basic-step-5d">5.d. No: Escalate to Issue</dt>
+<dd><p>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. </p>
-<p>The issue tracker issue should reference the original bugzilla
-bug. The bugzilla bug will reference the issue and have the
+<p>The Tracker Issue should reference the original Bugzilla
+bug. The Bugzilla bug will reference the issue and have the
TrackerIssue keyword added.</p>
-<p>Note: comments with additional information may still be added to a
-bugzilla bug after it has been escalated to the tracker.</dd>
+<p><b>Note:</b> comments with additional information may still be added to a
+Bugzilla bug after it has been escalated to the Tracker.</p>
+
+<p><b>Clarification:</b>It's not correct per this policy to both
+escalate a bug to the Tracker <em>and</em> 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.</p></dd>
+
+<dt>5.e. No, But Willing to Concede: Close Bug and mark Disagree</dt>
+<dd>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. <b>** This is an endpoint for the process. **</b></dd>
<dt>6. Working Group Decision</dt>
-<dd>Issues escalated to the tracker will be decided by Working Group Decision. The <a href="#escalation">Escalation Process</a> describes how Working Group decisions are made.</dd>
+<dd>Issues escalated to the Tracker will be decided by Working Group Decision. The <a href="#escalation">Escalation Process</a> describes how Working Group decisions are made.</dd>
<dt id="basic-step-7a">7.a. Affirm Editor's Response</dt>
-<dd>The Working Group Decision that results from the Escalation Process may be to affirm the editor's response. In this case proceed to <a href="#basic-step-8">step 8</a>.</dd>
+<dd>The Working Group Decision that results from the Escalation Process may be to affirm the Editor's response. In this case proceed to <a href="#basic-step-8">step 8</a>.</dd>
<dt id="basic-step-7b">7.b. Overrule Editor's Response</dt>
-<dd>The Working Group Decision that results from the Escalation Process may be to overrule the editor's response. In this case proceed to <a href="#basic-step-10">step 10</a>.</dd>
+<dd>The Working Group Decision that results from the Escalation Process may be to overrule the Editor's response. In this case proceed to <a href="#basic-step-10">step 10</a>.</dd>
<dt id="basic-step-8">8. Does Commenter Wish to Formally Object?<dt>
<dd>The commenter should decide at this point if they wish to enter a Formal Objection against the Working Group decision.</dd>
@@ -180,7 +341,7 @@
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
+Bugzilla bug, and the bug should be placed in the CLOSED state and
tagged with the FormalObjection keyword. <b>** This is an endpoint for
the process. **</b></dd>
@@ -194,10 +355,13 @@
<dt id="basic-step-10">10. Tag Bug as WG Decision and Reopen</dt>
<dd>The bug is reopened indicating the WG decision, and tagged with
[864 lines skipped]
--- /sources/public/html5/decision-policy/decision-policy-v1.html 2013/04/23 12:00:04 NONE
+++ /sources/public/html5/decision-policy/decision-policy-v1.html 2013/04/23 12:00:04 1.1
[1219 lines skipped]
Received on Tuesday, 23 April 2013 12:00:10 UTC