TPAC/2011/Agile Standardization

From W3C Wiki
< TPAC‎ | 2011
(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
Tab Atkins and Fantasai
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.


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.