Revised Specification Process

The current specification development process is confusing, inconsistent, and difficult to follow. We need to tweak the approach we're taking to developing the specification...

Proposal: Separate Stable, Checkpoint and Dev Streams for the Specification and Shindig

• The Stable Stream would include the current stable version of the specification that only includes completed, non-incubating stuff. This will be the best target for developers who are looking to implement only fully-baked, tested and proven interoperable features. 
• The Dev Stream would be where all new work happens. This is effectively the "trunk" where all changes to the specification, no matter how minor, roll in. At regular intervals (e.g. every two weeks) and as individual items are completed, the Dev Stream will roll over into an updated Checkpoint.
• The Checkpoint Stream would contain the ongoing snapshot of work being produced by the Dev Stream. Checkpoint drafts are essentially Release Candidates for stable. Upon complete testing, review and implementation, a particular Checkpoint version can be rolled over as the current "Stable" version. Any specific instance of the Checkpoint draft can be declared as "Stable" once consensus is reached.

To kick off the process, version 2.5 would become the first Stable Spec. 

All work for 3.0 items would be done within the Dev stream, with periodic Checkpoint Drafts coming out every two weeks.

The process is similar in nature to that used in many other places, including Chrome (http://dev.chromium.org/getting-involved/dev-channel).