W3C home > Mailing lists > Public > public-html@w3.org > October 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 18:58:59 -0700
Cc: HTMLWG WG <public-html@w3.org>
Message-id: <F2991780-8E4B-46B7-81A1-14958BD1DFF1@apple.com>
To: Paul Cotton <Paul.Cotton@microsoft.com>

On Oct 20, 2009, at 6:39 PM, Paul Cotton wrote:

> > 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?

Sorry, I meant to say:

"Ian tells me that, given the way he edits the spec (with a long  
processing pipeline before the change is fully committed, and often  
multiple edits in flight), it is awkward to include a diff link in the  
bug at the time the bug is resolved."

My point in mentioning this was:
- We already have the desired info in the other direction (from commit  
comments to bug numbers).
- Ian says it would be hard to put the info directly in bugzilla  
without disrupting his workflow. Typically by the time the finished  
spec is committed to dev.w3.org cvs, the bug has long since been  
resolved.
- Since we already have the reverse mapping, let's use an automated  
solution to produce the forward mapping instead of asking Ian to do  
more work by hand.

Regards,
Maciej

>
> /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
Received on Wednesday, 21 October 2009 01:59:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:50 GMT