Re: Protected Policy on Repository Merging Process

Your words seem to imply that editors have to have permission from the
group every time the make a commit. That has never been true, and every
editor in this WG routinely commits changes without specific WG approval.

I for one, cannot and will not work as an editor if I have to have group
approval to perform every commit. If that is someone's idea of how to get
this editor to stop work and leave the group, then you are correct, that
will be the result.

Please let me know if I no longer have the confidence of the group, and I
will gladly turn over all of TTML editing to you.

On Sat, Nov 11, 2017 at 12:11 PM, Glenn Adams <glenn@skynav.com> wrote:

> Are you accusing an editor of making unilateral modifications? Can you
> provide proof of such an allegation and describe how it was remedied?
>
> 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-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.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
>