W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > March 2019

Re: Note on PR approval process and responsibilities

From: pedro winstley <pedro.win.stan@googlemail.com>
Date: Wed, 20 Mar 2019 19:02:23 +0000
Message-ID: <CABUZhHnTmiO48cKnWy2RGEgwQ7P-EyO1KWwprkw39VzHXTeWcg@mail.gmail.com>
To: Rob Atkinson <rob@metalinkage.com.au>
Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
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.

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
Received on Wednesday, 20 March 2019 19:02:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:15 UTC