Spec Advancement Process Proposal
test and implementation driven agile spec advancement
One of the most common criticisms of the CSSWG is that specs/features take too long. In particular many features have been implemented with vendor prefixes, inconveniencing authors and implementers alike for *years* and resulting in a need to maintain support for prefixed properties (or worse).
This proposal provides improvements that encourage rapid draft advancement based on implementations and tests. - Tantek 2012-038
principles
Drafts should:
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 the group as a whole, but they're also designed for individual editors to follow as a way to more rapidly advance their drafts.
<html><span style=“font-size:2em;font-weight:bold;vertical-align:-.1em;line-height:0.5em”>✍</span></html>→ED. Any member of the CSSWG may check-in an editor's draft to present ideas/content for consideration. Contents of the draft must be within the WG charter. Any objections raised by CSSWG 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*.
This assessment is made at the CSSWG telcon/f2f.
Since the CSSWG telcon is on Wednesday and the draft publication occurs the next Tuesday, if anyone posts a public test case document that disproves the interoperability before that Monday, 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.
LC→LC updates may be published per editor discretion, e.g. when more features are implemented, which may result in fewer being *at-risk*. This 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.
See Also
