Adding a document describing the phases through which a proposal will…

… pass.

process/phases.md

@@ -0,0 +1,150 @@
+# WebAssembly W3C Process
+
+This file describes how feature proposals will progress through
+the standardization process.
+
+In general, the process moves forward through a series of numbered phases.
+However, if issues are uncovered or consensus devolves,
+proposals should back up to the appropriate prior step.
+
+## 0. Feature Proposal [CG]
+
+Entry requirements:
+  * A CG member has an idea.
+
+During this phase a new repository forking the spec repo is created (CG members
+can request this). PRs + Issues iterate on the design of the feature. If human
+readable design repo style .md files are useful, these are added to describe
+the feature as it's being designed. A tracking issue is created in the design
+repo.
+
+If relevant to demonstrate the viability of a feature, prototype
+implementations of the feature are implemented in interested engines (possibly
+on a branch).
+The CG will attempt to reach broad consensus.
+
+## 1. Proposed Spec Text Available [CG/WG]
+
+Entry requirements:
+   * Full proposed english spec text available in a forked repo around which a
+     reasonably high level of consensus exists.
+   * *Updates to the formal notation, test suite,
+      and reference interpreter are NOT yet required*.
+
+During this phase, one or more implementations proceed on prototyping the
+feature to the point that a comprehensive set of tests can be added. These
+tests need not pass the reference interpreter at this point, but should pass on
+some implementation.
+
+## 2. Implementation Phase [CG/WG]
+
+Entry requirements:
+   * Test suite has been updated to cover the feature in its forked repo.
+   * The test suite should run against some implementation, though it need not be
+     the reference interpreter.
+   * *Formal notation in the spec need not be updated.*
+
+During this phase, the following proceeds in parallel:
+Web VMs (browsers) implement the feature.
+The forked repo is updated to include revisions to the formalisation.
+The forked repo spec is updated to include implementation of the feature in the
+reference interpreter (OCaml).
+The feature is implemented in toolchains.
+
+## 3. Standardize the Feature [WG]
+
+Entry requirements:
+   * Two or more Web VMs implement the feature.
+   * At least one toolchain implements the feature.
+   * The formalisation and the OCaml reference interpreter are usually updated
+     (though these two can be done as part of step 3 at the WG chair's discretion).
+     CG + general consensus has continued to this point (as throughout).
+
+At this point the feature is fully handed off to the WG.
+During this phase, WG members discuss the feature, consider edge cases, and
+work towards consensus that the feature is now complete (kicking it back to an
+earlier stage in the CG if issues are uncovered).
+
+## 4. The Feature is Standardized [WG]
+
+Entry requirements:
+   * Consensus is reached in amongst WG members that the feature is complete.
+
+When Working Group consensus is reached (online), editors can merge the feature
+into master on the spec repo.
+The W3C snapshots (for REC) are made at a regular cadence (in a W3C repo), used
+to stamp official version. Matching tags are added in the github spec repo.
+The feature is enabled on stable by various browsers, converging on all.
+
+
+## Example how this might work
+
+### Worker based Threads
+
+0. Feature Proposal
+   * Someone proposes adding threads to WebAssembly.
+   * A threads repo is created: https://github.com/WebAssembly/threads
+   * Once a human readable .md is agreed on describing behavior + opcodes,
+     work to update the spec's english text to reflect the change in a branch
+     occurs.
+     A few browsers begin to prototype atomic opcodes behind flag to demonstrate
+     feasibility.
+1. Proposed Spec Text Available
+   * The WG is informed of the thrads proposal.
+   * The proposed spec text is finalized describing the new opcodes for atomics,
+     memory model, etc.
+   * A test suite exercising threads is created. All the prototype
+     implementations can run it.
+2. Implementation Phase
+   * Work progresses to implement the agree opcodes for atomics in several
+     browsers.
+   * The OCaml interpreter is updated to simulate threads.
+   * The formal language in the spec is expanded to describe atomics and the
+     memory model.
+3. Standardized the Feature
+   * The WG examines the spec, looking for edge cases, testing gaps,
+     and unforseen interactions with other standards.
+   * Everything is in order.
+4. The Feature is Standardized
+   * WG member consensus is reached (potentially by distributed means).
+   * Editors merge the spec changes from the branch to master on the spec repo.
+   * Browsers turn on atomic ops by default.
+   * Profit!
+
+## FAQ
+
+#### Who owns the various existing W3C repos?
+
+They are owned in common by the WG + CG. The WG used the
+github.com/WebAssembly/spec repo to iterate on finalized proposals for hand-off
+to the W3C's snapshotted copy of the spec. The other repos are primarily
+overseen by the CG.
+
+#### What about licenses?
+
+The spec and spec forks will move to a W3C Documents and Software License.
+Other related repos for prototypes + tools will continue under their respective
+licenses.
+
+#### What is the CG for?
+
+Incubation.
+To provide a safe harbor for a broad set of stakeholders to discuss, design,
+and iterate on new features during Steps 1-3 above.
+It should attempt to address all concerns, but need not reach 100% consensus.
+
+#### What is the WG for?
+
+To finalize and ratify mostly complete specs + test suites from the CG.
+Changes to the spec need not have reached full consensus in the CG to move to
+the WG, but key WG stakeholders should resolve outstanding mismatch in the CG.
+
+#### Who will have admin rights + close issues etc?
+
+This can be distributed and handled by multiple folks.
+In terms of github issues specifically, chairs will mainly step in to drive
+consensus, keep discussions civil, and as a first escalation point if someone
+is unhappy with how the collaboration is conducted (for instance if someone is
+unhappy a particular issue was closed over their objections).
+This is a general part of their role in community building:
+https://www.w3.org/Guide/chair-roles