- From: Maciej Stachowiak via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 28 Jul 2010 02:52:52 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/decision-policy In directory hutz:/tmp/cvs-serv12134 Modified Files: decision-policy-v2.html Log Message: "Consider giving guidelines for use of different bug resolutions" http://www.w3.org/Bugs/Public/show_bug.cgi?id=9284 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 } </style> @@ -106,15 +107,76 @@ </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> + +<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: (descrption 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 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 +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. Does not require a full editor's +response.</td></tr> +<tr><td>DUPLICATE</td><td>Bug is the same issue as another bug. Does not require a full +editor's response.</td></tr> +</table> </dd> <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