Cet article est issue d’une série d’article sur le fonctionnement du CSS Working Group au W3C. L’article original a été écris en anglais par Fantasai.

Processus de spécification

Ce qui suit correspond au processus de recommandation du W3C. Officiellement il a six phases ; toutefois, au seins du CSS WG, nous considérons le procédé comme s’il ne comptait que trois phases, les autres n’étant que des transitions formelles pour nous :

Brouillon de travail (WD)

Ceci correspond à la phase de conception d’une spécification du W3C. le groupe de travail itère la spécification en réponse aux commentaires internes et externes.

Le premier brouillon de travail officiel est appelé « premier brouillon de travail public » (FPWD). Au sein du CSS WG, publier un FPWD indique que le groupe de travail s’est mis d’accord pour travailler sur le module, grossièrement ébauché et proposé comme le premier jet de l’éditeur.

Transition : Dernier appel à commentaire (LCWD)

L’étape suivante, que l’on considère comme une simple transition, est la phase de « dernier appel à commentaire » (LCWD). Le CSS WG fait cet appel à commentaire une fois que tous les problèmes ont été résolus, et qu’aucun avancement supplémentaire n’est possible sans un retour formel issue des tests et des implémentations.

Le LCWD fixe une date butoir pour signaler tout problème dans la spécification. Cette phase exige que le groupe de travail suive et traite les remarques de manière formel. Le document qui permet le suivi des commentaires est le « Disposition of Comments » (DoC). Il est soumis, avec une mise à jour du brouillon de la spécification, à l’approbation du directeur du W3C.

Recommandation candidate (CR)

Ceci est la phase de test d’une spécification du W3C. Notamment, cette phase est dédié à la mise en œuvre de tests et d’implémentations afin de tester la qualité de la spécification : il ne s’agit donc pas de tester la qualité des implémentations.

Pour pouvoir sortir de cette phase de CR, le groupe doit recevoir la preuve que deux implémentations correctes et indépendantes de chaque fonction ont été réalisés. Ainsi, pendant cette phase, le groupe de travail construit un ensemble de tests permettant de vérifier que les implémentations sont conformes à la spécification et génère des rapports d’implémentation.


Transition : Recommandation proposée (PR)

La transition vers l’étape suivante est la « Recommandation proposée » (PR). Au cours de cette phase, le comité consultatif du W3C doit approuver la transition vers l’état de « Recommandation ».

Recommandation (REC)

C’est l’état final d’une spécification du W3C et donc, une phase de maintien. À cette étape, le groupe de travail maintient les errata et occasionnellement publie une version corrigée qui incorpore les errata à la spécification.

Théoriquement, une spécification se déplace de manière linéaire tout le long de ce processus ; toutefois dans l’histoire du CSS WG, les spécifications font souvent marche arrière ou passent en marche accélérée en réaction à certains commentaires. Nous devenons de plus en plus rodé à la gestion des spécification selon ce processus et nous sommes devenus plus exigeants envers les spécifications que nous poussons à l’état de CR (cependant quelques failles existent dans le processus du W3C qui contraignent parfois les spécifications à revenir en arrière).

En 2007, j’ai redécoupé les étapes de développement d’une spécification du CSS WG. Ce découpage est plus fin et plus subjectif que la voie classique de recommandation du W3C, mais montre comment une spécification se développe et se stabilise avec le temps. (Comme pour la voie classique, les spécifications peuvent reculer ou avancer en fonction des remarques reçues.) Les types de changements qui sont gérés par le groupe de travail par rapport à l’éditeur dépend fortement du niveau de maturité de la spécification :

Exploration (pré-FPWD, début WD)

À cette étape, la spécification est souvent incomplète, des changements importants sont possibles entre les différents brouillons, et de nombreuses fonctionnalités peuvent être abandonnées au fur et à mesure que la spécification mûrit. L’éditeur doit signaler les changements importants et les nouvelles fonctionnalités au groupe de travail qui formule ses suggestions et conseils à l’éditeur ou prend des décisions officielles sur la construction et la porté du module. Autrement, l’éditeur à toute latitude pour incorporer les remarques et propositions qui font consensus. Un FPWD officiel est publié durant cette étape (ce qui est un signal fort indiquant que le CSS WG dans son ensemble souhaite adopter ce module) ainsi que de nombreux autres brouillons subséquents.

Révision (mi-WD)

À ce moment, le module est quasiment complet et l’ensemble de ses fonctionnalités est bien défini, cependant la spécification nécessite encore de nombreux cycles d’édition, de correction et de révision afin de soulever les problèmes et de les résoudre. Tandis que les changements touchant aux questions d’architecture sont expressément validés par le groupe de travail, l’éditeur se charge seul des problèmes non controversés.

À la fin de cette étape, le groupe de travail aura pris toutes les décisions concernant les fonctionnalités à conserver ou à garder pour cette version du module et l’ensemble des fonctions est figé en vue de l’étape CR.

Affinage (fin WD, LCWD)

La spécification est alors assez stable et presque prête pour devenir un recommandation candidate, cependant certaines modifications ciblées doivent être faites — par exemple, se charger d’incorporer les commentaires lié à la phase LCWD — ou un travail d’harmonisation global. Tous les problèmes majeurs, hormis les corrections d’erreurs évidentes et les clarifications, doivent passer par le groupe de travail pour qu’une résolution formel soit prise. Cette étape correspond au LCWD, mais peut aussi inclure la publication d’un brouillon de travail préliminaire à un dernier appel à commentaire (pour éradiquer les derniers problèmes avant de débuter le processus formel de LCWD : cela permet d’éviter d’avoir plusieurs derniers appels à commentaire).

Essai (début CR)

À partir de ce point le groupe de travail considère que la spécification est assez complète et précise pour être implémentée, et qu’aucun progrès ne peut être fait sans un retour d’expérience lié aux implémentations. En même temps que la spécification devient une recommandation candidate, le groupe de travail publie donc un appel aux implémentations et aux tests. À cette étape tous les changements qui ne sont pas éditoriales doivent être formellement approuvés par le groupe de travail, et la numérotation des sections est figée.

Stable (fin CR)

A ce moment, le groupe de travail considère qu’il dispose d’assez de retour d’expérience en provenance des tests et des implémentations pour considérer la spécification comme stable et fiable. Les problèmes rapportés ne sont plus aussi fréquents et souvent mineurs ; les implémentations couvrent totalement la spécification ; Enfin, tous les tests qui ne sont pas passés par deux implémentations sont suffisamment bien compris pour être considéré comme des bug d’implémentation qui pourront être corrigés. Cette étape est marquée par l’inclusion dans le dernier CSS Snapshot.

Complété (PR, REC)

C’est à cette étape que les rapports d’implémentation et d’essais sont bouclés, la spécification a quitté avec succès le statut de recommandation candidate, et, bien que les éditeurs soient chargés de maintenir les errata, aucun changement additionnel n’est à prévoir. Les modifications éditoriales non essentielles sont découragées, et tout changement important doit être approuvé par le groupe de travail.

À suivre : CSS WG — Sources d’innovation