RE: Editor's Response in the proposed process (with particular note of spec diff links)

> Ian tells me that, given the way he edits the spec (with a long processing pipeline before the change is fully committed,

This sentence looks like it is missing text after the comma.  Could you supply the missing text?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Maciej Stachowiak
Sent: Tuesday, October 20, 2009 8:39 PM
To: HTMLWG WG
Subject: Editor's Response in the proposed process (with particular note of spec diff links)

Hello WG & Editors,

I think it's time to start including the Editor's Response notes in bugzilla bug resolutions. We're informally starting to use other parts of the proposed Decision Policy and I'd like to start using the parts that apply to editor actions. I would also like to address Adrian Bateman's concern about

I'd like to ask editors to include the following boilerplate text (with the fields filled in appropriately) when resolving bugzilla bugs. Note: detailed rationale is not generally needed for minor editorial issues like typos. In general, bugs marked with the "NE" keyword should be considered non-editorial, i.e. they likely *do* need rationale. When in doubt, just put something brief like "Commenter was correct" or "This is not a typo, it's by design" or something along those lines.

(Boilerplate is between the rows of dashes.)

-------------

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: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: ["Accepted"/"Partially Accepted"/"Rejected"]
Change Description: ["no spec change", or explain actual spec change]
Rationale: [give rationale for change or lack of change here]

---------------

Ian, Manu, please let me know if there are any issues with this.


The other piece of information we would like in every resolved bugzilla bug is a link to the relevant revision of the spec. I've talked to Ian about this so far, not yet other editors. He is including the bugzilla bug number in every commit. Ian tells me that, given the way he edits the spec (with a long processing pipeline before the change is fully committed,

Therefore: I'd like to ask for a volunteer to write a tool to add the spec diff information to bugzilla bugs. It should be a simple matter of looking at commit messages for completed commits, and adding the appropriate comment programatically. I'd like the comment to have this format:  "Diffs to Spec Text:http://dev.w3.org/cvsweb/html5/spec/Overview.html.diff?r1=1.3360&r2=1.3361". Can any of the people familiar with the spec production toolchain please help with this?


I'd like to ask other editors of specs with a Working Draft (I think only Manu currently) to please include the bug number in their commit messages, or just include a line in the above format in the EDITOR'S RESPONSE template itself.


Adrian: given the current status (bug numbers being included in the commit messages), are you satisfied in your concerns, or would you like to wait until we have the final automated step integrated into the production pipeline?


Regards,
Maciej