W3C home > Mailing lists > Public > public-webrtc-editors@w3.org > October 2017

Re: Changing editors draft workflow

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 10 Oct 2017 05:03:48 +0000
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Dominique HazaŽl-Massieux <dom@w3.org>
CC: Bernard Aboba <Bernard.Aboba@microsoft.com>, Dan Burnett <danielcburnett@gmail.com>, "public-webrtc-editors@w3.org" <public-webrtc-editors@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B31588904E134884@ESESSMB105.ericsson.se>
On 2017-10-10 01:37, Cullen Jennings (fluffy) wrote:
>> On Oct 9, 2017, at 5:54 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
>> Le 06/10/2017 ŗ 22:58, Bernard Aboba a ťcrit :
>>> To clarify, this would mean that for webrtc-pc (the only document not yet at CR) there would be an editors' draft for each commit to master, right?  But that would end once the document is published as a CR?
>>> [BA] How would change logs work? 
>> Good question; I think our options are:
>> A. making the last step before a merge (or while doing the merge) that
>> editors add a matching line to the changelog
>> B. requiring them in pull requests, with a new format convention since
>> we would be moving away from specific date release; hopefully that
>> convention would avoid conflicts on merge (but I'm not too sure how)
>> C. removing changelogs from the document
>> D. having them updated at a different pace from editors draft (e.g.
>> weekly? biweekly?)
>> E. having them autogenerated from the commit logs (which would probably
>> require some convention for the commit messages)
>> F. having them maintained into a separate document
>> I would start with D while we figure out which of the others would
>> otherwise work better.
>> Dom
> I could live with any of the above but I think B makes the most sense to me. 

I'm leaning towards a combination of B and E. If we have well formatted
PR titles I don't think it's super necessary to maintain a separate
change log, but at the same time it shouldn't be to hard to have one
automatically generated with a summary at one location that also filters
out noise like minor editorial changes.

Some thoughts:

Can we have github labels or [keywords] in the commit message to filter
which changes that should go into the change log? For example, typo
fixes would be excluded.

Regarding a convention for PR titles. I think it would work if the
editors or the person reviewing a PR, also reviews the PR title and
checks if it follows the convention and makes sense. That would be done
all days of the week and not slow us down at the editor's call.
Regardless which way we go, I think this should be done.


Received on Tuesday, 10 October 2017 05:04:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:06 UTC