TTML2 Editing Process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

TTML2 Editing Process

Glenn Adams-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

nigelmegitt

Hi Glenn,

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.

Kind regards,

Nigel



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

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.

 

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

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this
 

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. 

I plan to create issues for existing editorial notes.
 

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.

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'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'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.
 

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.

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

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).
 

Kind regards,

Nigel



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

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.

 

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

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2


On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this

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.
 
 

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. 

I plan to create issues for existing editorial notes.
 

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.

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'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'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.
 

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.

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

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).
 

Kind regards,

Nigel



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

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.

 

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

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2
In reply to this post by Glenn Adams-2


On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this
 

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. 

I plan to create issues for existing editorial notes.
 

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.

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'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'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.
 

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.

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

To make this point more formal, I've added a section on lazy consensus to the editing process document, where I refer to [2] as a reasonable operational definition.

 

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).
 

Kind regards,

Nigel



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

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.

 

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

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

nigelmegitt
In reply to this post by Glenn Adams-2

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58

On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this

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.

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.


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.
 
 

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. 

I plan to create issues for existing editorial notes.

Thank you!

 

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.

That is a necessary requirement for publishing in any case.

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.

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'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'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.

I'm not proposing a change to the policy, just the mechanism for executing it.

 

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.

Incremental review prior to publishing a new WD is not increased by this process.

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.

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. 

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.


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

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.

 

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

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2


On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58

On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this

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.

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.


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.
 
 

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. 

I plan to create issues for existing editorial notes.

Thank you!

 

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.

That is a necessary requirement for publishing in any case.

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.

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'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'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.

I'm not proposing a change to the policy, just the mechanism for executing it.

 

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.

Incremental review prior to publishing a new WD is not increased by this process.

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.

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.

 

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.
 

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.
 


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

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.

 

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

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2


On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <[hidden email]> wrote:


On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58

On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:


On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> wrote:

Hi Glenn,

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?

OK, I will relax the guideline to allow this

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.

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.


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.
 
 

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. 

I plan to create issues for existing editorial notes.

Thank you!

 

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.

That is a necessary requirement for publishing in any case.

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.

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'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'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.

I'm not proposing a change to the policy, just the mechanism for executing it.

 

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.

Incremental review prior to publishing a new WD is not increased by this process.

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.

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.


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:

 
 

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.
 

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.
 


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

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.

 

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

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

nigelmegitt

From: Glenn Adams <[hidden email]Date: Tuesday, 10 May 2016 17:07
On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <[hidden email]> wrote:
On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:
On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> 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.


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 

 

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.

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.

 


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

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.

 

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

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2


On Tue, May 10, 2016 at 10:37 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Tuesday, 10 May 2016 17:07
On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <[hidden email]> wrote:
On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:
On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> 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.


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 

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

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.

 

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

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

nigelmegitt



On 10 May 2016, at 18:23, Glenn Adams <[hidden email]> wrote:



On Tue, May 10, 2016 at 10:37 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Tuesday, 10 May 2016 17:07
On Tue, May 10, 2016 at 10:02 AM, Glenn Adams <[hidden email]> wrote:
On Tue, May 10, 2016 at 9:29 AM, Nigel Megitt <[hidden email]> wrote:

From: Glenn Adams <[hidden email]Date: Monday, 9 May 2016 23:58
On Mon, May 9, 2016 at 10:53 AM, Glenn Adams <[hidden email]> wrote:
On Mon, May 9, 2016 at 5:24 AM, Nigel Megitt <[hidden email]> 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.


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 

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

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.

 

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

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Thierry Michel
In reply to this post by Glenn Adams-2
Hi,

Here are some info from the W3C process [1] and the "Organize a
Technical Report Transition (2015 Process)" [2] and Echidna [3].



W3C process [1] 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)" [2] 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
publication ...]


Last Echidna [3] 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
step".]

Hope this helps.


Thierry



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?

   [1] https://www.w3.org/2015/Process-20150901/#revised-wd

   [2]
https://services.w3.org/xslt?xmlfile=https://www.w3.org/2005/08/01-transitions2015.html&xslfile=https://www.w3.org/2005/08/transitions2015.xsl
  [3]
https://github.com/w3c/echidna/wiki/How-to-use-Echidna

Reply | Threaded
Open this post in threaded view
|

Re: TTML2 Editing Process

Glenn Adams-2
In reply to this post by Glenn Adams-2
After some discussion with Nigel, I have updated the Editing Process document to:
  • add section on nominal review period
  • add information about use of the following labels to help the editor and reviewers track merge related activity:
    • Merge Early - used to mark early merges
    • Merge Standard - used to mark non-early merges
    • Merge Objection - used to mark objections to merges
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:
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.