Re: Protected Policy on Repository Merging Process

If this policy change should be adopted by all WGs for all work in the w3c
repositories, then I may reconsider my position. However, I find it deeply
troubling that this policy change was imposed on the group without
discussion or agreement by the group.

On Mon, Nov 13, 2017 at 4:36 PM, Glenn Adams <glenn@skynav.com> wrote:

> I discussed this with a CSS member, and they indicated they thought that
> the CSSWG would not be adopting this policy change.
>
> On Mon, Nov 13, 2017 at 2:39 PM, David Singer <singer@mac.com> wrote:
>
>> 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-r
>> equest-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-c
>> onsensus-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.
>> >
>> >
>> >
>> >
>> >
>>
>> David Singer
>>
>> singer@mac.com
>>
>>
>>
>