Changing our Work Mode, and Raising the Bar: Call for Consensus

[Mark Nottingham <[e-mail]>]

As discussed both on-list and in Tokyo [1], we're getting to a stage where at least some of our documents would benefit from slower and slightly more formal process, so that the rate of change is not so high, changes that do occur are well-vetted, and the documents get closer to reflecting consensus in the working group.

In particular, the chairs and editors feel that the Invariants, Transport and TLS documents are ready for such a change.

I've created a PR that describes what we currently do (and will continue to do for the other documents, until they also transition) as the "early-stage" process, and a new "late-stage" process.

See:
 https://github.com/quicwg/base-drafts/pull/2479/files

In a nutshell, PRs won't be merged until the chairs flag the corresponding issue as `has-consensus`, after checking for consensus on the mailing list (although discussion can still take place on the issue). Note that this only affects `design` issues, not editorial ones.

The above is mostly a change in the bookkeeping and roles for how we record issue state; if you have feedback or questions, please make them here or on the PR, but barring any unforeseen hiccups, we should be merging that shortly, and the new process will apply to all currently open and new design issues against these drafts.


We also discussed "raising the bar" for new issues against these three drafts in Tokyo. Our charter says:

"""
Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified.
"""

Effectively, if we do this, we're saying that we have gained consensus on what remains in these documents, excepting their outstanding issues. 

That doesn't mean that new issues can't be raised against those drafts. However, new issues against them will be judged for whether they contain new information (in particular, security or interoperability impact), a clear technical default, or have significant (in the judgement of the chairs) support for further discussion. If the issue isn't well-described or atomic, it may be closed with a request to refactor, or refactored for you.

Again, this does not affect editorial issues.

Practically speaking, it means that new issues will be triaged by the Chairs -- not the editors (although they can still "claim" purely editorial issues) -- and those that don't meet the criteria above will be closed. Those that do will be labeled (again, by the Chairs only) as `design`.

It also means that all of the closed `design` issues against these drafts will be marked as `has-consensus`. Additionally, the `quicv2` issues against them will be closed and marked `has-consensus`.

The issues that will be labeled `has-consensus` (and closed, if still open) are listed here:
  https://github.com/quicwg/base-drafts/issues?q=is%3Aissue+is%3Aclosed+label%3Adesign+-label%3Ahas-consensus+-label%3A-http+-label%3Arecovery
  https://github.com/quicwg/base-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Aquicv2+label%3Adesign+-label%3Ahas-consensus+-label%3A-http+-label%3Arecovery

We believe that all of these issues have been discussed and the group has formed consensus on them; this only formalises that. Again, this does not (yet) affect the Recovery and HTTP documents.

After discussion, there seemed to be good support for doing this in Tokyo. If you have concerns or questions, please discuss them on-list; barring pushback, we'll adopt this on 5-Mar-2019. Raising the bar for our other drafts will be considered separately (but doesn't appear to be too distant).

Cheers,


1. See the minutes at: https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md#process-change-discussion

--
Mark and Lars, QUIC WG Chairs



--
Mark Nottingham   https://www.mnot.net/