Re: TTML2 Editing Process

On 10 May 2016, at 18:23, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:



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

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Tuesday, 10 May 2016 17:07
On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Monday, 9 May 2016 23:58
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto: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?

I'm saying that we can refer to this decision to meet echidna's requirements alongside successful review of PRs, each of which also constitutes a group decision as long as it meets the decision policy set out in the Charter.





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<mailto:glenn@skynav.com>>
Date: Sunday, 8 May 2016 22:56
To: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: TTML2 Editing Process
Resent-From: <public-tt@w3.org<mailto: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.

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




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

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.

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