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.

Prise de décisions

Comme défini dans le processus du W3C, le CSS WG prend des décisions par consensus. Le consensus dans le CSS WG est généralement évalué de manière bien plus informelle que dans la définition officielle du W3C. Nous débattons d’un problème jusqu’à ce que tout le monde semble être sur la même longueur d’onde, et ensuite le président en charge de la séance de travail demande s’il y a des objections puis, le cas échéant, demande au secrétaire de déclarer officiellement le problème comme RÉSOLU. Bien que parfois certains détails ou une confirmation finale puisse être demandé après coup par courriel, les résolutions officielles du CSS WG sont celles prises pendant les réunions formelles et enregistrées dans le compte-rendu.

Dans certains cas où le consensus n’est pas clair, les présidents mettent en place un sondage non-officiel. Si une des options obtient une majorité écrasante et que ceux qui s’y opposent acceptent de faire avec cette proposition, elle sera acceptée comme consensus par le CSS WG et la résolution sera publiée comme il se doit. Dans les cas où le manque de consensus est clair, les présidents peuvent alors reporter la résolution du problème à plus tard ou (si c’est approprié) ne pas apporter de modification. Dans le cas ou le CSS WG n’aboutit pas à un consensus sur un problème donné, le W3C dispose d’une procédures de vote formel. Jusqu’ici, le CSS WG n’a jamais eu recours à cette alternative.

Maintenir des standards existants exige que les acteurs clés (les personnes qui les implémentent et créent les contenus sur le Web) soient capables de s’aligner sur les modifications. Pour les spécifications matures, nous avons besoin que les changements mineurs soient suggérés et approuvés formellement par le groupe entier. Ceci permet de s’assurer que tout le monde s’accorde sur les modifications et dispose d’une chance de signaler les régressions et écueils potentiels.

D’un autre côté, établir de nouvelles spécifications demande beaucoup de réflexion et de travail de réécriture. Cela permet de réaliser de nombreuses modifications rapidement en réponse aux commentaires concernant la conception et les détails de la spécification. S’il fallait passer toutes les modifications essentielles au travers du filtre du processus de résolution du groupe de travail, cela serait trop restrictif et inefficace.

Au sein du CSS WG, les éditeurs ne sont pas seulement responsables des tâches éditoriales et de l’application des décisions du groupe de travail : une certaine autorité leur est déléguée afin qu’ils puissent agir comme premier responsable des réponses aux commentaires et adopter une vision technique et éditoriale cohérente de son module. Cependant, contrairement aux autres groupes de travail, l’éditeur n’est pas un dictateur parfois outrepassé par un comité supérieur. La prise de décision reste aux mains du CSS WG dans son ensemble. Les modifications significatives et/ou controversées doivent être approuvées par un consensus du groupe de travail. Ce qui est considéré comme « significatif » varie selon la maturité du module : pour les spécifications les plus jeunes, le CSS WG accepte plus facilement les modifications à la discrétion des éditeurs.

Il n’y a pas de processus pour « faire remonter » un problème au CSS WG. Les décisions du groupe de travail sont un processus par défaut, et la décision d’un éditeur en est une exception (bien que cela soit courant). Cette exception à lieu lorsque le changement est :

  • purement éditorial, ou
  • corrige de manière évidente une erreur ou un oubli, ou
  • n’est pas contesté et n’impose pas de modification majeure d’un point de vu conceptuel.

Dans tous les autres cas, il est attendu de l’éditeur qu’il signal le problème au groupe de travail au cours d’une réunion, si possible avec une proposition incluant sa vision pour résoudre le problème et/ou un résumé des commentaires reçus.

La supervision du CSS WG n’est pas qu’un système de surveillance — elle est aussi utilisée comme une méthode pour résoudre des problèmes et s’assurer de l’avancement du travail. Les éditeurs peuvent soumettre des problèmes au groupe de travail quand ils ne sont pas sûrs de la manière de les résoudre, ou qu’ils pensent pouvoir bénéficier de l’expérience ou de la vision d’autres personnes. Puisque le CSS WG est la plus haute autorité sur CSS, soumettre un problème au groupe de travail est une manière de résoudre définitivement un problème lorsque la discussion sur la liste de diffusion ne progresse plus.

Notre processus de prise de décisions permet de progresser rapidement sur les spécifications tout en s’assurant que tous les membres du groupe de travail sont au fait de tout ce qui se passe dans CSS tout en ayant la possibilité de faire des modification et des commentaires. Cela permet de concentrer l’attention et l’expertise des membres du groupe sur les problèmes, permet de s’assurer que tous ceux qui implémentent sont d’accord avec les dernières avancées de CSS, évite les lourdes procédures d’appel, et permet au CSS WG d’assurer une cohérence entre tous les modules de CSS et dans la durée.

À suivre : CSS WG — Modularité