Re: TTML2 Editing Process

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