Re: Protected Policy on Repository Merging Process

So, you are confirming that this policy change is a vote of no confidence
on the editors.

On Sat, Nov 11, 2017 at 12:04 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Wearing my IMSC 1.1 editor hat, I object to the proposal below, and
> support experimenting with blocking merges until there is at least one
> approved review by another member.
>
> Time will tell if blocking merges will slow down the process, and the
> group can reconsider in a month or two.
>
> In the meantime, this will prevent unilateral modifications by the
> editor, which are even more harmful to the quality of the
> specification and the publication schedule.
>
> On Sat, Nov 11, 2017 at 12:27 AM, 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-merging
> >>
> >> 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-applies
> >>
> >> 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.
> >>
> >>
> >>
> >>
> >
>