This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given the new cool URL we have, I suggest that we simplify the boilerplate to the following: """ EDITOR'S DECISION (see http://dev.w3.org/html5/decision-policy/decision-policy.html on how to respond to it if needed) (rationale) """ If implemented, I don't believe that this change will require a version change.
I'd prefer EDITOR's RESPONSE rather than EDITOR'S DECISION, as many confuse Editor's proposed resolutions as Working Group Decisions. I'd prefer a more specific URL, something like http://dev.w3.org/html5/decision-policy/decision-policy.html#basic-step-2 And perhaps to make it even more stable, changing the anchor to #editors-response. --- As to how the decision policy itself would need to change, clearly the boilerplate would have to be removed, the description of the resolutions can stay, and the part of the boilerplate that talks about potential next steps becomes part of the text of the decision policy. What needs to be discussed is the following bullets: * 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. The proposed boilerplace covers #2, but doesn't clearly cover #1 and #3. My take is that these are reasonable items for people to expect in a proposed resolution. Thoughts?
(In reply to comment #1) > I'd prefer EDITOR's RESPONSE rather than EDITOR'S DECISION, as many confuse > Editor's proposed resolutions as Working Group Decisions. That's actually what I meant, thanks for catching that. > I'd prefer a more specific URL, something like > > http://dev.w3.org/html5/decision-policy/decision-policy.html#basic-step-2 > > And perhaps to make it even more stable, changing the anchor to > #editors-response. That works for me; I don't have a strong preference as the anchor name. > As to how the decision policy itself would need to change, clearly the > boilerplate would have to be removed, the description of the resolutions can > stay, and the part of the boilerplate that talks about potential next steps > becomes part of the text of the decision policy. What needs to be discussed > is the following bullets: > > * 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. > > The proposed boilerplace covers #2, but doesn't clearly cover #1 and #3. My > take is that these are reasonable items for people to expect in a proposed > resolution. Thoughts? How about making it: (Accepted|Rejected) (Rationale) (Pointer to change) ?