Re: TTML2 Editing Process

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


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