RE: Protected Policy on Repository Merging Process

I sent a separate email about addressing the two stage commit - it should not require manual input at all: it is a continuous integration/deployment task that we should be able to automate.

Just in the same way as David is on the hook for editorial merge changes for WebVTT, I am happy to be on the hook for this for TTML1 and TTML2. I would also ask Thierry to provide backup for this in case I happen to be away or unable to be as responsive as usual.

Nigel


________________________________
From: Glenn Adams [glenn@skynav.com]
Sent: 14 November 2017 05:50
To: David Ronca
Cc: Andreas Tai; David Singer; TTWG; Philippe Le Hegaret
Subject: Re: Protected Policy on Repository Merging Process

Just to be clear where I stand, I have no objection to this new policy for substantive issues; however, I do have problems with its application to editorial issues and other types of upkeep and maintenance pushes. One particular aspect of TTML{1,2} editorial process that doesn't hold for the other repositories is the use of a two stage commit process, whereby we push primary changes to ttml2.xml and then use a separate process to build and push an updated ttml2.html. In general, this has been done via multiple commits into gh-pages (and master before that). Indeed, an approximately 50% of the commits are to regenerate the html file. The proposed new process will require that every push go through a PR and review. For TTML repos, this means that we may see many PRs that do nothing other than regenerate the ED. IMO, this adds a considerable burden to the editing process that those who don't work with this process fail to appreciate.


On Tue, Nov 14, 2017 at 5:27 AM, David Ronca <dronca@netflix.com<mailto:dronca@netflix.com>> wrote:
Perhaps everyone can agree that this is a good model going forward.  It is troubling, however, that we are debating a change that was already made, apparently with very little input from the working group.

David

On Mon, Nov 13, 2017 at 8:33 PM, <tai@irt.de<mailto:tai@irt.de>> wrote:
I support the new policy to require a pull request review before merging. It is a common practice in software development and helps keeping the quality of the code. The same applies to standards. We may find possible blockers beforehand and encourage group members to participate in the editing process.

We can reassess the decision after some months of practical experience.

Best regards,

Andreas
-----Ursprüngliche Nachricht-----
Von: David Singer [mailto:singer@mac.com<mailto:singer@mac.com>]
Gesendet: Montag, 13. November 2017 13:39
An: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Cc: Philippe Le Hegaret <plh@w3.org<mailto:plh@w3.org>>
Betreff: Re: Protected Policy on Repository Merging Process

I am on the hook to do approvals for the VTT spec. (one of the approvers) and indeed it’s an easy task if the edit truly is editorial. But in another group I am in, someone realized that an edit that the editor thought editorial actually did have implications (both for function and readability) and we had to revert, which was more painful.

CSS at least is considering (may already have decided) to move to a “no direct edits” model, where  every change to a document under WG change management is done via Pull Requests. Under these circumstances, the editor would normally have their own GitHub repo that represents their best thinking and they’d PR into the group repo, which means that the editor’s latest version of the document is in their repo, and at least one other person has confirmed the changes to the WD in the group’s repo.

I don’t think either of these are terribly burdensome (not nearly as burdensome as some other things we have to do).

> On Nov 11, 2017, at 1:27 , Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
>
> Regarding the following, I propose the following:
>       • that a special label, "protected", be used to designate whether an issue is subject to commit protection control, where any member can add this label, but only the chair (or his delegate) may remove it, and where it is understood that this label is intended to be applied only to non-editorial or non-trivial issues that should be subject to a reviewed PR process;
>       • that application of protection semantics be restricted to those issues having the protected label; that is, if an issue has the protected label, then a commit to gh-pages is not permitted unless another member approves the review of a PR associated with the issue;
>       • that the non-consensus policy change recently imposed to effect
> commit protection semantics be reversed and deferred until the above two points are implemented; G.
>
> On Fri, Nov 10, 2017 at 12:52 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
> I just discovered that, as an editor, I cannot make a trivial editorial change to the TTML2 repository without an approved review by another member.
>
> This new policy was apparently established without discussion or review by the group, and directly contravenes existing group practice and standing policies.
>
> For example, in the standing (group approved) TTML2 Editing Process,
> we have [1], which states
>
> The editor may merge a PR, with or without changes, at any time, subject to the review period guidelines described above. The editor may delegate the merging of a PR to the creator of the PR or to another party. If merging a PR has been delegated, then the editor and delegatee should coordinate mergers to avoid unintended conflicts.
>
> If a PR merge is effected prior to the end of the nominal review period, then a Merge Early label must be applied to the associated issue.
>
> PR merges occur only from a PR branch to the gh-pages (default) branch.
>
> [1]
> https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#pull-request-mer

> ging
>
> Furthermore, we have [2]:
>
> This project operates on the principles of lazy consensus, a reasonable description of which can be found at Apache Rave™ Project.
>
> [2]
> https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#lazy-consensus-a

> pplies
>
> The new, unapproved policy, contravenes the application of the approved and standing process in a number of ways, including
>       • imposes a review-then-commit (RTC) policy on an existing commit-then-review (CTR) policy;
>       • eliminates editor prerogative to perform merge, specifically, editorial or trivial changes;
>       • effectively forces every change whatsoever, no matter how trivial, to require going through a pull request (PR) process.
> This change will have an immediate deleterious effect on the nature and timeliness of performing common editor tasks. I predict it may result in a 50 to 100% delay of schedule in the process of going from WD to REC. It will most certainly push out the TTML2 specification's schedule in significant manner.
>
> Finally, this change is, in my opinion, a vote of no confidence for all editors, in the sense that it removes a default level of trust in editors that has applied for the history of this group.
>
> Consequently, I strongly object to this change, and ask the chair and W3M to reconsider this draconian, and unapproved top-down mandatory policy change.
>
> G.
>
>
>
>
>

David Singer

singer@mac.com<mailto:singer@mac.com>










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

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.

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