From W3C Wiki
Revision as of 22:01, 3 May 2012 by Tantekelik
- be published early and often to show interest/activity
- transparently note objections/issues
- advance as rapidly as implementations and tests show interest/interop
- drop/postpone features lacking implementation(s) to not hold up interoperable features
process for advancement
Here are proposed improvements to accelerate the advancement of specs. These improvements can be adopted by a group as a whole, but they're also designed for individual editors to follow as a way to more rapidly advance their drafts.
- ✍->ED. Any member of the group may check-in an editor's draft to present ideas/content for consideration. Contents of the draft must be within the group charter. Any objections raised by group members must be noted in the ED.
- ED->WD. When any feature is implemented (as shown by publicly posted test case document), a public working draft is published.
- WD->LC. When any feature is interoperably implemented by more than one implementation, the WD is automatically published as a LC with a 6 week review period. Any unimplemented feature is marked *at-risk*.
- The interoperability assessment can be made at a group telcon/f2f (additional sync decision suggestions welcome).
- If anyone posts a public test case document that disproves the interoperability after the assessment but before W3C publication process completes publication, the LC is merely published as another WD.
- When anyone posts public test case document(s) that disproves interoperability of all previously shown interoperable features, the LC review period clock is stopped.
- When implementations are updated to once again demonstrate interoperability of at least one feature, the 6 week LC review period is restarted as of that date.
- LC->LC updates may be published per editor discretion, e.g. when more features are implemented, which may result in fewer being *at-risk*. Publishing an update restarts a new 6 week LC review period.
- LC->CR. At the end of the LC review period, the LC is automatically published as a CR with a 6 month implementation period. Any unimplemented features are dropped and postponed to the next version. Any features with only one implementation, or not interoperably implemented are marked *at-risk*.
- CR->CR updates may be published per editor discretion, e.g. when more features are interoperably implemented, which may result in fewer being marked *at-risk*. The 6 month implementation period is *not* restarted.
- CR->PR. At the end of the CR implementation period, the CR is automatically published as a PR. Any features that are not interoperably implemented are dropped and postponed to the next version.
- PR->REC. Follow standard W3C process. Suggestions welcome.