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