Re: Protected Policy on Repository Merging Process

Regarding the following, I propose the following:

   1. 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;
   2. 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;
   3. 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
> <https://rave.apache.org/docs/governance/lazyConsensus.html>.
>
> [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.
>
>
>
>
>