I have documented the (new) TTML2 Editing Process . 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.
Thank you for this – it'll be great to start using pull requests like this, and I appreciate your flexibility in changing the editorial process, and thoroughness in documenting it. A couple of questions and a request:
1. The process excludes the possibility of merging into a PR branch from another branch: I think there could be a legitimate reason for doing this occasionally, so I'm not sure why we would prohibit it?
2. Since the process requires an issue number, do you plan to create issues for each editorial note that needs further work? Some of those editorial tasks could usefully be completed by group members via PRs. Alternatively a different naming format for non-issue editorial fixes could work.
The other thing to note is that since this process does not require consensus prior to merging, we will need a separate review phase for every snapshot that we wish to consider for publication as a WD. I'm guessing you've chosen that route so that you can resolve any temporal blockages caused by waiting for consensus, as discussed in last week's meeting.
I suppose I'd just request that where possible you do wait for a consensus prior to merging, since that will reduce our incremental review time prior to publishing new WDs. If we can keep track of those PRs that you merge without consensus, that would be helpful.
From: Glenn Adams <[hidden email]>
Date: Sunday, 8 May 2016 22:56
To: TTWG <[hidden email]>
Subject: TTML2 Editing Process
Resent-From: <[hidden email]>
Resent-Date: Sunday, 8 May 2016 22:57
On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:
OK, I will relax the guideline to allow this
I plan to create issues for existing editorial notes.
That is a necessary requirement for publishing in any case. However, since each PR and its merge can be reviewed incrementally, and follow-on issues can be created to address post-merge problems, then that "separate review phase for every snapshot" can be of a very short duration provided folks are paying attention to PR merge notifications and doing post-merge reviews in a timely fashion, rather than waiting for the "separate review phase" to catch up with their reviews.
I've chosen to retain CTR policy because that is what we have been using since 2003, and because I believe this lies at the heart of an editor's privileges and responsibilities.
Incremental review prior to publishing a new WD is not increased by this process. 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.
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.
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).
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:
After further consideration, I don't see an apparent reason to do this. PR branches should remain issue specific. And each PR branch is associated (by name) with a given issue. So if you merged a PR branch associated with issue 1 with a PR branch associated with issue 2, then merged that result into gh-pages, you will have two issues which PR have been intermixed from the perspective of gh-pages history. This sounds like a bad idea indeed.
So I think the best option for now is leave the current guideline in place until someone has a real case where merging a PR branch into another PR branch makes more sense than not.
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:
To make this point more formal, I've added a section on lazy consensus to the editing process document, where I refer to  as a reasonable operational definition.
I agree that would be bad, but that isn't the use case. The use case is where someone wants to make a change to a branch that's the source for a PR for an issue, as described at https://lists.w3.org/Archives/Public/public-tt/2016May/0028.html This could occur if there's contention regarding the correct way to resolve an issue, or a complex further edit is proposed by someone other than the original creator of the branch. It's also possible to commit directly to the source branch of course, by agreement.
This is an edge case though, so I propose we continue with the scheme you've outlined and address any issues with the process if they arise.
Actually it would be satisfied by reviewing each PR with WD publication in mind – then after the pull request has been merged the new version on gh-pages would be suitable for automated publishing as a WD on /TR. This doesn't prevent a parallel branch from being maintained representing an editor's draft, which could be some commits ahead.
I'm not proposing a change to the policy, just the mechanism for executing it.
I wasn’t clear what I meant by "incremental": I meant the extra time needed post pull request merge in order to get to WD publication. When we're able to confirm consensus prior to the merge then zero incremental time is needed to publish a new WD – the Editor or Chair can just do it. If we need to go back and check we have consensus then some incremental review is introduced.
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.
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.
On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:
The echidna process requires a group decision . 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.
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.
They should have the initial PR creation email notification in their mailbox. They can use that as an index of what to review.
On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <[hidden email]> wrote:
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:
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
Yes, it's good to clarify.
Not everyone likes to get notifications.
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.
On Tue, May 10, 2016 at 10:37 AM, Nigel Megitt <[hidden email]> wrote:
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?
They are free to use other means to keep tabs on activity.
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.
On 10 May 2016, at 18:23, Glenn Adams <[hidden email]> wrote:
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.
Here are some info from the W3C process  and the "Organize a
Technical Report Transition (2015 Process)"  and Echidna .
W3C process  does not require a record the group's decision) for
publication of a new version of a WD.
[.. To publish a revision of a Working draft, a Working Group must
record the group's decision to request publication. Consensus is not
required, as this is a procedural step,]...
It also says
[.. Working Drafts do not necessarily represent a consensus of the
Working Group, and do not imply any endorsement by W3C or its members
beyond agreement to work on a general area of technology]...
Now looking at the "Organize a Technical Report Transition (2015
Process)"  it says for publication of an ordinary working draft:
[... Here are the W3C Process Document transition requirements for a
Working Draft: The Group must record the group's decision to request
Last Echidna  says
[... Group decision
Every publication needs to point to the Working Group decision to
publish, per the 2015 Process: "must record the group's decision to
request publication. Consensus is not required, as this is a procedural
Hope this helps.
Le 10/05/2016 à 19:22, Glenn Adams a écrit :
> 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?
After some discussion with Nigel, I have updated the Editing Process document to:
The Merge Early label is mandatory; while the Merge Standard label is optional. A PR merge that went the full nominal review period before merge is not mandated to have a Merge Standard label, which can be assumed to apply.
Part of the goal in refining this language is to provide enough framework to permit reviewers sufficient comfort level in managing reviews of early merges, and, further, that it should be possible for this process to be used by multiple documents|editors, e.g., TTML2 and IMSC2, where it becomes the editor's prerogative as to whether to take advantage of early merges or not.
On Sun, May 8, 2016 at 3:56 PM, Glenn Adams <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|