Merge pull request #12 from quicwg/master

Align with master 2019/06/04

CONTRIBUTING.md

@@ -67,21 +67,54 @@ Issues will be labeled by the Chairs as either `editorial` or `design`:
 
 * **Editorial** issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
 
-The `open` design issues in the issues list are those that we are currently or plan to discuss. When a design issue is `closed`, it implies that the issue has a proposed resolution that is reflected in the drafts; if a `closed` design issue is labeled with `has-consensus`, it means that the incorporated resolution has Working Group consensus.
+The open design issues in the issues list are those that we are currently discussing, or plan to discuss. They can be discussed on the mailing list or the issue itself.
 
-Design issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to design issues for the group's consideration by incorporating them into the draft(s).
+We're currently using two different processes for issue resolution, depending on draft maturity.
+
+Note that in both processes, we use the `has-consensus` flag to denote an issue that we have consensus upon. Whether or not a design issue is closed does **not** reflect consensus of the Working Group; an issue's `open`/`closed` state is only used to organise our discussions.
+
+If you have a question or problem with an issue in the `closed` state, please comment on it (either in the issues list or mailing list), and we'll adjust its state accordingly. Note that reopening issues with `has-consensus` requires new information.
+
+
+### Early-Stage Process
+
+The early-stage process gives more powers to the editors to incorporate what they believe to be the Working Group's position into the drafts; the focus of these drafts is on flexibility, so that changes don't have an inordinate amount of overhead.
+
+In this process, the editors can propose resolutions to design issues for the group's consideration by incorporating them into the draft(s), closing the issue.
 
 When a new draft is published, the design issues that have been closed since the last draft will be highlighted on the mailing list, to aid reviewers. Once consensus is confirmed, those issues will be labeled with [`has-consensus`](https://github.com/quicwg/base-drafts/issues?utf8=✓&q=label%3Ahas-consensus%20).
 
-Note that whether or not a design issue is closed does **not** reflect consensus of the Working Group; an issue's `open`/`closed` state is only used to organise our discussions. If you have a question or problem with an issue in the `closed` state, please comment on it (either in the issues list or mailing list), and we'll adjust its state accordingly. Note that reopening issues with `has-consensus` requires new information.
+When a design issue is `closed`, it implies that the issue has a proposed resolution that is reflected in the drafts; if a `closed` design issue is labeled with `has-consensus`, it means that the incorporated resolution has Working Group consensus.
+
+The drafts currently in the early stage are:
+
+* HTTP/3
+* QPACK
+* Recovery
+
+
+### Late-Stage Process
+
+The late-stage process attempts to reflect the Working Group's current consensus in the drafts; the latest draft reflects that consensus, modulo any open (or undiscovered) issues. The goal for a late-stage draft is to reduce unnecessary design changes in the protocol, thereby aiding reviewers and assuring that the drafts accurately reflect consensus.
+
+In this process, the Working Group will discuss each design issue, and the Chairs will judge consensus, labelling the issue as `has-consensus` (ideally based upon a Pull Request that specifies the exact changes to be made).
+
+Only after that will the change be merged and the issue be closed.
+
+The drafts currently in the late stage are:
+
+* Invariants
+* Transport
+* TLS
+
+![diagram of the late stage workflow](workflow.png "Late Stage Workflow")
 
 ### Discretionary Design Issue Labels
 
 We also use the following labels to help understand the state of our design issues:
 
 * [`arch`](https://github.com/quicwg/base-drafts/labels/arch): The issue is a higher-level architectural issue that should drive the solution to a number of other issues.
 * [`needs-discussion`](https://github.com/quicwg/base-drafts/labels/needs-discussion): The issue blocks progress to our next milestone.
-* [`has-proposal`](https://github.com/quicwg/base-drafts/labels/has-proposal): The issue has a proposal for resolution.
 * [`editor-ready`](https://github.com/quicwg/base-drafts/labels/editor-ready): The Working Group believes it has a viable resolution, but the editors need to incorporate that into the document so we can see it in situ.
 
 

README.md

@@ -39,14 +39,6 @@ QUIC protocol suite.
 * [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-qpack)
 * [Compare Working Group Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt)
 
-## Spin Bit Experiment
-
-This is a non-milestone draft describing the spin bit for interop testing purposes
-
-* [Editor's copy](https://quicwg.github.io/base-drafts/draft-ietf-quic-spin-exp.html)
-* [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-spin-exp)
-* [Compare Working Group Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-spin-exp&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-spin-exp.txt)
-
 ## Building the Draft
 
 Formatted text and HTML versions of the draft can be built using `make`.