- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Wed, 20 Mar 2019 12:31:24 +1100
- To: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
- Message-ID: <CACfF9LzcHLShXbXxAghSt=NPtnd72Ni6hv920GB_bU-XGhypNw@mail.gmail.com>
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 01:32:24 UTC