Spec Advancement

From W3C Wiki
Revision as of 22:01, 3 May 2012 by Tantekelik (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Spec Advancement

This is an ongoing project to accelerate the advancement of specifications through the W3C Process. - Tantek Çelik

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 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.

See Also