TPAC/2011/Agile Standardization
(Redirected from TPAC2011/Agile Standardization)
Agile Standardization within the W3C Process
Developing standards for living technologies within the existing W3C Process
- Chaired by
- Steve Zilles
- Speakers
- Tab Atkins and Fantasai
- Channel
- #agile
- Slides
- http://www.xanthir.com/talks/2011-11-02/
- Time
- 1:30-2:30
- Place
- Ballroom D
A number of people have expressed concerns that the W3C process inhibits agile specification development. This need not be the case. Fantasai and Tab Atkins will share their experience of how the CSS Working Group develops a major Web technology as a living standard within the W3C process. We'll talk about techniques for successful modularization, the specification development process, the editor/WG authority split, and mixing sources of innovation. Steve Zilles will moderate and expand the discussion to how these techniques can be applied in other WGs.
If you can't make the session, Fantasai has blogged about the CSSWG Process in detail.
Summary
- Modularize
- Write a tightly-scoped bedrock spec and then build the rest on top of that, leaning heavily on good definitions/categories to minimize messy interconnections and interdependencies.
- Level by Stability
- Allow individual modules to level independently, and punt unstable features from a spec to minimize the time it cycles in an unstable state. Allow the module to exist at multiple levels, each in a different state: unstable (WD), testing (CR), maintenance (REC). This way you can maintain stable specs, stabilize features, and add new features to WD at the same time.
- Communicate Stability
- The Working Draft status is actually composed of multiple maturity stages, which should be recognized within the group and communicated to outside developers.
- Delegate by Stability
- Editors should be delegated more authority in the beginning to iterate swiftly and to ensure a consistent voice and vision, with the WG gradually taking more oversight to ensure correctness and compatibility as the spec matures.
- Honor all input
- Innovation comes from specs, implementations, and users. Integrate their input.
- Involve all stakeholders
- All stakeholders should be involved at all stages. Actively ensuring every stakeholder (WG member or not) has eyes on the spec is necessary to avoid a painful spec process.