Re: TTML2 Editing Process

On Tue, May 10, 2016 at 10:37 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> From: Glenn Adams <glenn@skynav.com> Date: Tuesday, 10 May 2016 17:07
>
> On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>> On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>> wrote:
>>
>>> From: Glenn Adams <glenn@skynav.com> Date: Monday, 9 May 2016 23:58
>>>
>>> On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <glenn@skynav.com> wrote:
>>>
>>>> On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>>> wrote:
>>>>
>>>>> [snip]
>
>
>>> The echidna process requires a group decision [3]. So the Editor or
>> Chair can't simply pull the trigger. Again, by lazy consensus, if a team
>> member has not objected to a prior PR merge, then consensus is present.
>>
>> [3]
>> https://www.youtube.com/watch?v=yI-7mQUTiXI&src_vid=0SRonXlRHXk&annotation_id=annotation_880483967&feature=iv
>>
>
> Oops. I appear to have pasted in a link from a FB thread from yesterday
> rather than the echidna documentation. Please disregard this link, and use
> the following instead:
>
> [3] https://github.com/w3c/echidna/wiki/How-to-use-Echidna#group-decision
>
>
>
> We had this discussion and already made the decision. It was recorded at
> the end of the Tools agenda item on day 1 of our Sapporo meeting - see
> https://www.w3.org/2015/10/28-tt-minutes.html#item05
>

I'm not sure what you are saying. Are you saying that we can ignore
echidna's requirement to refer to a group decision? If so, then what
publishing process shall we use?


>
>
>>
>>>
>>> It is still amortized as if RTC were used. The only difference is that
>>>> the review increments start at the time each PR is created, and may
>>>> continue after the PR merge, while in the RTC approach PR merge doesn't
>>>> occur until review is complete.
>>>>
>>>
>>>>
>>>>> If we can keep track of those PRs that you merge without consensus,
>>>>> that would be helpful.
>>>>>
>>>>
>>>> I have assume that "silence means agreement", i.e., "lazy consensus"
>>>> applies; so it will be the responsibility of a reviewer to speak up if
>>>> there is an issue with the results of a PR merge. They can do that
>>>> incrementally as PRs are proposed and merged.
>>>>
>>>
>>> I'd be interested to know how group members feel about this. If there
>>> are no objections to this way of working then it can indeed work.
>>>
>>
>> This is how all the work on TTML1 and TTML2 were done to date. I agree it
>> may not have been documented well, but it was certainly discussed and
>> agreed upon long ago. So this isn't nothing new.
>>
>> What is new, is that the group membership has changed in recent years,
>> and we haven't managed to fully articulate the principles that we were
>> operating under, including that of lazy consensus.
>>
>> I thought it appropriate now to document this fact to avoid confusion in
>> the future.
>>
>
> Yes, it's good to clarify.
>
>
>>
>>>
>>> The potential difficulty is that it makes it harder for keen but busy
>>> people to track which PRs they need to review, since some of them may
>>> already be closed.
>>>
>>
>> They should have the initial PR creation email notification in their
>> mailbox. They can use that as an index of what to review.
>>
>
> Not everyone likes to get notifications.
>

They are free to use other means to keep tabs on activity.


>
> Another useful thing we could do is add Consensus and No Consensus labels
> and use them on Pull Requests – github is good at filtering PRs and issues
> on label, so it would be a low cost mechanism independent of merge state.
>

There is no need for a Consensus label, since that state is present
implicitly by lazy consensus rules. If however, an objection is recorded on
a PR before its merge, then we could apply an Non-Consensus label to record
explicit non-consensus.

If an objection appears post-merge, then a new issue should be entered,
referring to the original issue or PR. That follow-on issue could have an
Objection label.




>
>
>>
>>>
>>>
>>>> Clearly, it would be a bad idea for the editor to preemptively merge a
>>>> PR he knows ahead of time will be controversial or produce an objection. It
>>>> will be his judgement about whether to merge and when that may occur (if at
>>>> all).
>>>>
>>>
>>> Good point.
>>>
>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Nigel
>>>>>
>>>>>
>>>>>
>>>>> From: Glenn Adams <glenn@skynav.com>
>>>>> Date: Sunday, 8 May 2016 22:56
>>>>> To: TTWG <public-tt@w3.org>
>>>>> Subject: TTML2 Editing Process
>>>>> Resent-From: <public-tt@w3.org>
>>>>> Resent-Date: Sunday, 8 May 2016 22:57
>>>>>
>>>>> I have documented the (new) TTML2 Editing Process [1]. This process
>>>>> adopts the standard github pull-request mechanism; therefore, it provides
>>>>> the advantages of fine-grained review of issue-based merges.
>>>>>
>>>>> The only variation to what has been followed with IMSC1 is that I have
>>>>> retained the commit-then-review (CTR) process that has been used for TTML1
>>>>> and TTML2 to date.
>>>>>
>>>>> [1] https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------
>>>>>
>>>>> http://www.bbc.co.uk
>>>>> This e-mail (and any attachments) is confidential and may contain
>>>>> personal views which are not the views of the BBC unless specifically
>>>>> stated.
>>>>> If you have received it in error, please delete it from your system.
>>>>> Do not use, copy or disclose the information in any way nor act in
>>>>> reliance on it and notify the sender immediately.
>>>>> Please note that the BBC monitors e-mails sent or received.
>>>>> Further communication will signify your consent to this.
>>>>>
>>>>> ---------------------
>>>>>
>>>>
>>>>
>>>
>>>
>>> ----------------------------
>>>
>>> http://www.bbc.co.uk
>>> This e-mail (and any attachments) is confidential and may contain
>>> personal views which are not the views of the BBC unless specifically
>>> stated.
>>> If you have received it in error, please delete it from your system.
>>> Do not use, copy or disclose the information in any way nor act in
>>> reliance on it and notify the sender immediately.
>>> Please note that the BBC monitors e-mails sent or received.
>>> Further communication will signify your consent to this.
>>>
>>> ---------------------
>>>
>>
>>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>