RE: Protected Policy on Repository Merging Process

It may be a technical change, but in terms of the general approach in which we make specification changes with consensus, it is no change at all. Glenn was correct in his statement that it is still possible to merge changes with both an approval review and a request changes review, so this adjustment is not expected to tackle all cases, and a merge when changes have been requested would be considered exceptional.

>From a practical perspective, as well as being led by the approach that Phillippe has put forward to improve group effectiveness, I also believe it will both encourage participation and speed up our work, since we can make a decision based on an issue, implement it, and move on, rather than committed editorial changes being the starting point for a discussion. As we get closer to a TTML CR publication, this is more important than ever.

Nigel

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

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>