W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 20 Oct 2009 17:38:42 -0700
Cc: WebApps WG <public-webapps@w3.org>
Message-id: <23D2157F-369B-4330-8F49-794CB4B69896@apple.com>
To: Maciej Stachowiak <mjs@apple.com>

Whoops, sent this to the wrong list, my apologies.

  - Maciej

On Oct 20, 2009, at 5:30 PM, Maciej Stachowiak wrote:

> 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
>
Received on Wednesday, 21 October 2009 00:39:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT