Note on PR approval process and responsibilities

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