Re: Note on PR approval process and responsibilities

I have reiterated the nature of editors drafts and W3C processes (as we
spend a lot of time on this and its not apparently clear to all) to support
smooth operation of the proposed approach.

Can you identify exactly where any new restrictions are placed on PRs in
this regard?  I think the only trivial restriction here is the obvious one
that we only need to vote on PRs for the head (gh-pages). The thing about
process is that it does need to be explicit, and this just captures the
direction given by @plh and the consensus of the last plenary.

I have suggested a restriction that reviews respect the status of editors
drafts and the publish-early mantra of W3C, as we seem to be losing the
sense of that, but this doesnt change best practice in any way - just
reminds editors and contributors that open issues are the way to handle
non-consensus - not blocking the release of editors drafts that correctly
reference these open issues.

As this reflects my understanding of the process, if there are specific
divergences of opinion it would be helpful to get these out there and
discussed _before_ the plenary..

rob


On Thu, 21 Mar 2019 at 06:02, pedro winstley <pedro.win.stan@googlemail.com>
wrote:

> Rob
> We agreed just to try it out and see how we got on.  That means that we
> just give it a go.
> Also, we weren't wanting to be restrictive about specifying what people
> were allowed to think about any PR or anything.
> I'm hopeful that if we get 2 reviews of the proposed PRs then it will be a
> simple matter for the plenary to agree to the merge.
> Cheers
> Peter
>
> On Wed, 20 Mar 2019 at 01:33, Rob Atkinson <rob@metalinkage.com.au> wrote:
>
>>
>> The implications of the PR process are unchanged w.r.t. the nature of
>> PRs, with the addition of a plenary decision to merge. So its important to
>> remember what editors drafts,  PRs and PWDs are supposed to do and not less
>> process confusion stymie progress.
>>
>> So to reflect on the underlying principles and ground rules, and to make
>> the proposed process tenable, we need to collectively recognise, and apply
>> discipline in plenary to stay within scope of discussions:
>>
>> 1) PRs to be voted on are PRs specifically on the "editors draft" of
>> documents, proposed and or reviewed by the editors. (PRs on other branches
>> should not be considered)
>> 2) Such drafts reflect the editor's responsibility to reflect the current
>> state, including open issues where consensus has not been reached.
>> 3) PRs must accurately reflect the consensus of any issues due for closing
>> 5) documents such as wiki pages and google docs etc that support
>> asynchronous editing and suggestions are not normative or long term
>> archives. They must therefore be time-bounded and a state captured by
>> editors. This may include any open issues
>> 6) PWDs do not need to reflect consensus (@plh) and the philosophy is
>> publish early and often - so open issues are the way to carry on
>> conversations, not interfering with editorial processes such as negative
>> reviews because of a personal disagreement or lack of clarity. Procedures
>> exist to suggest changes.
>> 7) Negative reviews on PRs should be limited to explicit and
>> process-relevant criteria - such as broken formatting, easily fixed
>> editorial typos and misspellings or incorrect transcription of the
>> consensus in a concluded (due for closing) issue, or not referencing a
>> pertinent open issue related to the PR.  note that this explicitly excludes
>> matters that require open issues - such as suggestions for different
>> wording. This last point is critical because otherwise it becomes a closed
>> conversation between a reviewer and editors denying the wider group the
>> opportunity to contribute by the existing processes.
>> 8) PRs should be fairly fine-grained with a small number of related
>> commits, and separation of editorial commits and substantive content
>> changes.
>> 9) changes to normative sections of specifications should be flagged for
>> attention in changes sections in documents.
>> 10) Agendas and PRs for closing must be available 24 hours in advance,
>> and it is the responsibility of all to make specific comments on PRs in
>> advance of the meeting. The default position should be acceptance in the
>> absence of a specific comment, and it should be possible to review the
>> comment and decide on action in the meeting (accept anyway, accept with
>> prescribed changes (backed by an ACTION) or convene a special meeting to
>> resolve the issue. I dont think it should be possible to simply reject PRs
>> based on content since they reflect the editor's view of the draft, and
>> reviewers are already responsible for it meeting the relevant sub-group's
>> determinations - but it should be OK to raise an issue and include if some
>> substantive issue is identified. So a problem requires an issue to be
>> identified as relevant but not present in the draft already or a new one
>> raised and included - and PRs progressed anyway.
>>
>> This meets both existing editorial role requirments and the declared
>> intent of plenary consensus which is to gain visibility of changes, without
>> interfering with the sub-group work on preparing content and exploring
>> issues.
>>
>> I know this is probably obvious to most, and mainly just reflects the
>> best practice, but I feel it is worth reiterating so such a conversation
>> does not take up a lot of the next plenary before we actually move forward
>> on such a vote.
>>
>> Rob Atkinson
>>
>>