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> 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> 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]
>> Gesendet: Montag, 13. November 2017 13:39
>> An: TTWG <public-tt@w3.org>
>> Cc: Philippe Le Hegaret <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> 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> 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
>>
>>
>>
>>
>>
>>
>