W3C home > Mailing lists > Public > public-html-commits@w3.org > July 2010

html5/decision-policy decision-policy-v2.html,1.13,1.14

From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 28 Jul 2010 02:52:52 +0000
To: public-html-commits@w3.org
Message-Id: <E1OdwlI-0003Ao-B1@lionel-hutz.w3.org>
Update of /sources/public/html5/decision-policy
In directory hutz:/tmp/cvs-serv12134

Modified Files:
Log Message:
"Consider giving guidelines for use of different bug resolutions"

Index: decision-policy-v2.html
RCS file: /sources/public/html5/decision-policy/decision-policy-v2.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- decision-policy-v2.html	28 Jul 2010 02:33:24 -0000	1.13
+++ decision-policy-v2.html	28 Jul 2010 02:52:50 -0000	1.14
@@ -8,7 +8,8 @@
 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 }
@@ -106,15 +107,76 @@
 <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>
+<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>
 <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
+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: (descrption of spec change if any)
+Rationale: (rationale)
+<p>For any responses that involve a spec change a link to the relevant
+spec diffs should also be provied.</p>
+<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><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 issue.</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
+<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. Does not require a full editor's
+<tr><td>DUPLICATE</td><td>Bug is the same issue as another bug. Does not require a full
+editor's response.</td></tr>
 <dt>3. Verify Response Info</dt>
@@ -222,7 +284,7 @@
 <tr><td>UNCONFIRMED, NEW, ASSIGNED, REOPENED</td> <td>Waiting for editor response.*</td></tr>
 <tr><td>REOPENED and WGDecision</td> <td>Waiting for editor to implement Working Group decision.*</td></tr> 
-<tr><td>RESOLVED</td><td>Editor has addressed issue, waiting for boilerplate.*</td></tr>
+<tr><td>RESOLVED</td><td>Editor has addressed issue, waiting for review by verifier.*</td></tr>
 <tr><td>VERIFIED (and none of the below)</td><td>Waiting for response from commenter.*</td></tr>
 <tr><td>VERIFIED and TrackerRequest</td><td>Reporter requested escalated to Working Group. Waiting for mechanics of escalation.*</tr>
 <tr><td>VERIFIED and TrackerIssue</td><td>Reporter escalated to Working Group. Waiting for Working Group decision.*</tr>
Received on Wednesday, 28 July 2010 02:52:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:09:55 UTC