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