Le document de processus du W3C

7 Le processus de développement des rapports techniques du W3C

Le processus de développement des rapports techniques du W3C est l'ensemble d'étapes et de règles auquel les groupes de travail du W3C se soumettent pour normaliser une technologie Web. Les processus observés par un groupe de travail pour gérer le cahier des charges et les directives (appelées rapports techniques dans cette section) sont les suivants :

Le processus de développement des rapports techniques du W3C est conçu pour maximiser le consensus autour du contenu d'un rapport technique, assurer une qualité technique et éditoriale élevée, favoriser la cohérence des spécifications et emporter l'adhésion du W3C et de la communauté au sens large. Voir également la politique d'autorisation d'exploitation des recommandations du W3C dans la section 2 de La politique de brevets du W3C [PUB33].

Les sections suivantes décrivent :

On décrit d'abord les degrés de maturité puis les étapes du processus de développement des rapports techniques et leurs règles.

7.1 Les degrés de maturité

Le degré de maturité d'un rapport technique publié indique sa position dans le processus de développement. Les degrés de maturité version de travail et note de groupe de travail représentent les états initiaux possibles d'un rapport technique dans le processus de développement. Inversement, les degrés de maturité recommandation, note de groupe de travail et recommandation abrogée représentent les états finaux possibles.

7.1.1 Le degré de maturité d'un travail en cours

Version de travail (WD)
Une version de travail est un document publié par le W3C pour révision par la communauté, à savoir les membres du W3C, le public et d'autres organisations techniques. Les versions de travail, mais pas toutes, visent le statut de recommandation ; cf. la section de statut du document d'une version de travail pour connaître les objectifs du groupe.

7.1.2 Les degrés de maturité du suivi de recommandation

Outre les versions de travail visant la recommandation, les autres degrés de maturité du suivi de recommandation sont les suivants :

Recommandation candidate (CR)
Une recommandation candidate est un document que le W3C estime suffisamment vérifié et qui satisfait aux exigences techniques du groupe de travail. Le W3C publie une recommandation candidate afin de rassembler une expérience issue des mises en œuvre.
Recommandation proposée (PR)
Une recommandation proposée est un rapport technique mature qui, après une vérification approfondi de sa validité technique et de la viabilité de sa mise en œuvre, a été transmis au Comité consultatif du W3C pour approbation.
Recommandation du W3C (REC)
Une recommandation du W3C est une spécification ou un ensemble de directives qui, au terme d'une élaboration détaillée par consensus, a reçu l'approbation des membres du W3C et du Directeur. Le W3C recommande le large déploiement de ses recommandations. Remarque : Les recommandations du W3C sont similaires aux standards publiés par d'autres organisations.

7.1.3 Le degré de maturité à la fin des travaux sur un rapport technique

Note de groupe de travail
Une note de groupe de travail est publiée par un groupe de travail à charte pour signifier la fin des travaux sur un thème particulier. Un groupe de travail PEUT publier comme note de groupe de travail un document qui a été publié ou non comme version de travail précédemment.

Remarque : Afin d'éviter les confusions dans la communauté des développeurs et les médias, pour distinguer les documents qui représentent la production des groupes à charte et ceux qui sont des suggestions pour les activités du W3C (les soumissions de membre et les soumissions de l'Équipe), le W3C a cessé d'employer le degré de maturité non qualifié note.

7.1.4 Le degré de maturité à l'édition d'une recommandation

Recommandation éditée proposée
Une recommandation éditée proposée est une recommandation publiée en vue de la révision des changements suggérés par la communauté, dont certains peuvent influer sur la conformité. Lorsqu'il y a consensus à propos des changements, le document est publié en tant que recommandation.

7.1.5 Le degré de maturité à l'abrogation d'une recommandation

Recommandation abrogée
Une recommandation abrogée est une recommandation entière que le W3C ne reconnaît plus.

7.1.6 Les degrés de maturité des rapports techniques des groupes d'intérêts et de coordination

Le W3C PEUT également publier des notes de groupe d'intérêts et des notes de groupe de coordination. Puisque l'étiquette version de travail du W3C est si fortement associée aux produits livrables des groupes de travail du W3C (notamment ceux du suivi de recommandation), le W3C publie donc des notes de groupe d'intérêts/coordination) pour leurs travaux en cours et ceux terminés.

7.2 Les règles de promotion générales du suivi de recommandation

Préalablement à la promotion au statut de recommandation candidate ou aux degrés de maturité suivants, et jusqu'à la publication en tant que recommandation y compris, le groupe de travail DOIT :

  1. Enregistrer la décision du groupe de réclamer une promotion ;
  2. Présenter une documentation publique de tous les changements (importants ou bien mineurs) survenus sur le rapport technique depuis l'étape précédente. Un changement important (qu'il s'agisse d'une suppression, d'une inclusion ou d'une autre modification) est un changement qui est susceptible, raisonnablement, d'invalider une révision ou une expérience de mise en œuvre. Les autres changements (par exemple, les éclaircissements, les réparations de programme, les remaniements de texte et les autres corrections d'erreurs mineures) sont des changements mineurs ;
  3. Signaler, le cas échéant, quelles sont les exigences du groupe de travail pour ce document qui ont changé depuis l'étape précédente ;
  4. Signaler tous les changements à propos des dépendances avec d'autres groupes ;
  5. Faire la preuve d'une révision approfondie ;
  6. Répondre formellement à toutes les questions soulevées à propos du document depuis l'étape précédente ;
  7. Signaler toutes les objections formelles.

Les informations suivantes sont importantes pour la décision de promotion d'un rapport technique et elles DOIVENT donc être rendues publiques :

Cf. le chapitre Comment organiser une transition dans le suivi de recommandation dans Le guide des membres qui donne des conseils pratiques afin de remplir ces conditions.

7.3 Les révisions et les responsabilités de révision

L'expérience montre que les principes suivants facilitent l'apparition d'un consensus autour d'un rapport technique :

  1. Une publication fréquente (cf. l'obligation de vie d'un groupe de travail) ;
  2. Une révision précoce, qui permet de trouver rapidement les erreurs et de réduire les risques de technologies divergentes ;
  3. Une révision approfondie, y compris par d'autres groupes au sein ou hors du W3C.

Un document est vérifié dès sa première publication. Commençant avec la première version de travail publique et jusqu'au début de la révision en dernier appel, un groupe de travail DEVRAIT répondre formellement à toute remarque importante concernant un rapport technique et DEVRAIT le faire rapidement.

Commençant avec la révision en dernier appel et jusqu'à la transition vers la recommandation proposée, un groupe de travail DOIT répondre formellement à toute remarque importante concernant un rapport technique et DEVRAIT le faire rapidement. Lorsqu'un groupe de travail réclame une promotion au statut de recommandation candidate ou supérieur, le Directeur attend une documentation expresse confirmant que les problèmes ont reçus des réponses formelles (par exemple, dans une liste des problèmes avec leur traitement).

Le Directeur DOIT répondre formellement à tout problème important soulevé par les représentants au Comité consultatif pendant les périodes de révision de recommandation proposée, recommandation éditée proposée ou recommandation abrogée proposée. Le groupe de travail DOIT communiquer au Directeur (habituellement par l'intermédiaire du contact d'Équipe) tous les problèmes importants soulevés, pendant les périodes de révision des statuts de recommandation proposée, recommandation éditée proposée ou recommandation abrogée proposée, par des tiers autres que les représentants au Comité consultatif.

Les rapporteurs NE DEVRAIENT PAS envoyer de commentaires techniques importants tard dans le cours du suivi de recommandation. Les rapporteurs NE DEVRAIENT PAS attendre d'un groupe de travail qu'il effectue immédiatement des changements importants sur un document mature. Plus le groupe de travail pourra démontrer l'étendue de la révision, moins les remarques importantes tardives auront de poids pour le suivi de recommandation. Les idées valables DEVRAIENT être enregistrées même si elles ne sont pas incorporées à un document mature.

Le groupe de travail DOIT pouvoir démontrer qu'il a essayé de répondre aux rapporteurs et de leur apporter satisfaction. Les rapporteurs PEUVENT enregistrer une objection formelle à chaque fois qu'ils sont insatisfaits de la manière dont un groupe de travail aura traité un problème.

Un groupe de travail DEVRAIT négocier un calendrier de révision avec les autres groupes chargés de vérifier un document, y compris les liaisons concernées.

Deux périodes de révision formelle ont des durées fixes pour la promotion vers la recommandation : l'une après une annonce en dernier appel et l'autre après un appel à révision d'une recommandation proposée. Par considération pour le groupe de travail, les rapporteurs DEVRAIENT envoyer leurs remarques tôt au cours de la période de révision. Un groupe de travail NE DEVRAIT PAS démarrer une nouvelle révision avant la fin prévue de la révision en cours (par exemple, ne pas lancer une nouvelle révision en dernier appel avant la fin prévue pour la révision en dernier appel en cours).

Normalement, les rapporteurs NE DEVRAIENT PAS signaler de problèmes techniques importants à propos d'un rapport technique après la fin d'une période de révision en dernier appel. Néanmoins, cette situation peut se présenter et, comme indiqué précédemment, l'obligation du groupe de travail de répondre formellement aux problèmes perdure jusqu'au début d'une période de révision de recommandation proposée. Par contre, afin de permettre au groupe de travail de progresser sur un rapport technique, celui-ci PEUT refuser d'apporter des changements importants pour réponse aux problèmes signalés entre la fin d'une période de révision en dernier appel et la publication d'une recommandation. Un rapporteur PEUT enregistrer une objection formelle.

Les représentants au Comité consultatif NE DEVRAIENT PAS (mais ils le PEUVENT) signaler de nouveaux problèmes techniques importants pendant une période de révision au statut de recommandation proposée. Le Directeur PEUT répondre au rapporteur après la clôture de la période de révision de recommandation proposée. Remarque : Il peut être nécessaire de changer le niveau de confidentialité lorsque que les représentants au Comité consultatif signalent des problèmes au groupe de travail.

Pendant la révision par les membres, le groupe de travail DEVRAIT également répondre formellement aux problèmes pertinents et documentés, non signalés par le Comité consultatif (par exemple, par le public ou un autre groupe de travail du W3C), et les signaler rapidement au Directeur.

Lorsqu'un groupe de travail prend connaissance d'un problème important après la fin de la période de révision de recommandation proposée, le groupe DOIT répondre au rapporteur mais il PEUT refuser de répondre formellement au problème. Auquel cas, le groupe de travail PEUT traiter le problème au cours du suivi des erreurs.

7.4 La promotion d'un rapport technique vers la recommandation

Le W3C suit les étapes suivantes pour la promotion d'un rapport technique au statut de recommandation :

  1. Publication de la première version de travail public ;
  2. Annonce en dernier appel ;
  3. Appel de mises en œuvre. Remarque : Le Directeur PEUT autoriser le groupe de travail à sauter cette étape si les conditions d'admission à la suivante sont déjà satisfaites ;
  4. Appel à révision d'une recommandation proposée ;
  5. Publication comme recommandation.

En général, les groupes de travail se lancent dans cette tâche avec l'intention de publier une ou plusieurs recommandations. Toutefois, le W3C PEUT terminer les travaux sur un rapport technique à tout instant, ou il PEUT demander à un groupe de travail de conduire d'autres travaux, éventuellement en répétant une ou plusieurs étapes.

Entre la publication de la première version de travail publique et l'annonce en dernier appel, un groupe de travail publie des révisions qui contiennent généralement des changements importants. Entre deux étapes après une annonce en dernier appel, le groupe de travail PEUT publier une nouvelle version du rapport technique, au même degré de maturité, à condition qu'il n'y ait aucun changement important depuis l'étape précédente.

L'Équipe DOIT aviser le Comité consultatif et les autres groupes du W3C de la révision d'une recommandation candidate ou d'une recommandation proposée.

Ces étapes du processus de développement des rapports techniques peuvent consommer beaucoup de temps ; on encourage donc les participants à lire Les astuces pour arriver plus vite à la recommandation [PUB27].

Cf. le paragraphe Comment organiser une transition du suivi de recommandation dans Le guide des membres qui donne des renseignements pratiques pour préparer les révisions et les annonces des diverses étapes.

7.4.1 La première version de travail publique

Degré de maturité du document : Version de travail.

Annonce : Le Directeur DOIT annoncer la publication de la première version de travail aux autres groupes du W3C et au public.

But : La publication de la première version de travail publique constitue un signal adressé à la communauté pour commencer la révision du document. Cf. la section 4.1 de la politique de brevets du W3C [PUB33] pour des précisions concernant les implications de cette politique pour la première version de travail publique.

Conditions d'admission : Le président DOIT enregistrer la décision du groupe de réclamer la promotion. Puisque c'est la première fois qu'un document avec ce nom abrégé apparaît dans l'index des rapports techniques, l'approbation du Directeur est OBLIGATOIRE pour la transition.

Poursuite des travaux : Après publication de la première version de travail publique, le groupe de travail vérifie généralement le rapport technique (cf. l'obligation de vie d'un groupe de travail) conformément à sa charte.

Afin de présenter les versions de travail à un large public tôt au cours de leur développement, les conditions de publication se limitent à l'accord à publier d'un groupe de travail à charte et à la satisfaction des règles de publication de l'Équipe [PUB31]. Le consensus n'est pas obligatoire pour l'accord à publier ; le groupe de travail PEUT réclamer la publication d'une version de travail même si elle est instable et ne satisfait que partiellement aux exigences du groupe.

Les groupes de travail DEVRAIENT encourager une révision précoce et étendue du rapport technique, au sein et hors du W3C, en particulier par les autres groupes de travail dépendant du rapport technique. Les représentants au Comité consultatif DEVRAIENT encourager une révision au sein de leurs organisations dès le statut de première version de travail publique, c'est-à-dire, avant une annonce en dernier appel et bien avant un appel à révision d'une recommandation proposée.

Le groupe de travail DEVRAIT être réactif et faciliter la poursuite de la révision en répondant rapidement aux problèmes et en indiquant clairement les changements survenus entre deux versions (par exemple, en fournissant des diffs et des résumés des changements importants).

Étapes suivantes possibles :

7.4.2 L'annonce en dernier appel

Degré de maturité du document : Version de travail.

Annonce : Le groupe de travail DOIT faire l'annonce en dernier appel auprès des autres groupes du W3C et du public. Une annonce en dernier appel DOIT :

  1. Indiquer la date limite pour le dépôt des commentaires de révision ;
  2. Identifier les dépendances connues et solliciter une révision par tous les groupes de travail dépendants ;
  3. Solliciter une révision par le public.

But : Une annonce en dernier appel d'un groupe de travail est un signal selon lequel :

En général, une annonce en dernier appel est également le signal que le groupe de travail prévoit de promouvoir le rapport technique au degré de maturité supérieur.

Un groupe de travail DEVRAIT collaborer avec les autres groupes avant une annonce en dernier appel afin de réduire les risques de surprises en dernier appel.

Idéalement, après une annonce en dernier appel, un groupe de travail ne reçoit plus que des témoignages de soutien au document, sans proposition de changement important. En pratique, les annonces en dernier appel génèrent des critiques qui se traduisent parfois par des changements importants au document. Un groupe de travail NE DEVRAIT PAS présumer en avoir fini de sa tâche en vertu de la publication d'une annonce en dernier appel.

Conditions d'admission : Avant l'annonce en dernier appel, le groupe de travail DOIT réaliser les démarches suivantes :

  1. Enregistrer la décision du groupe de réclamer la promotion ;
  2. Remplir les conditions nécessaires de la charte du groupe de travail et celles des documents des besoins qui peuvent l'accompagner, ou bien signaler les obligations concernées qui n'ont pas été remplies ;
  3. Indiquer quelles sont les dépendances avec les autres groupes que le groupe de travail estime avoir satisfaites et signaler celles ne pas l'avoir été.

Durée de la révision : L'annonce marque le début d'une période de révision qui DEVRAIT durer au moins trois semaines mais qui PEUT être prolongée si le rapport technique est complexe ou si ses dépendances extérieures sont significatives.

Poursuite des travaux : Pendant la période de révision, le groupe de travail sollicite et répond aux commentaires de l'Équipe, des membres, des autres groupes du W3C et du public.

Il importe de s'assurer qu'un rapport technique s'insère correctement dans un contexte international. À compter de ce statut du processus de recommandation, le rapport technique DEVRAIT inclure une déclaration concernant la place de la technologie vis-à-vis des standards internationaux existants et des travaux apparentés menés en dehors du W3C.

Étapes suivantes possibles :

7.4.3 L'appel de mises en œuvre

Degré de maturité du document : Recommandation candidate.

Annonce : Le Directeur DOIT annoncer l'appel de mises en œuvre au Comité consultatif.

But : À ce stade, le W3C estime que le rapport technique est stable et prêt pour une mise en œuvre. Le rapport technique PEUT encore changer en fonction de l'expérience retirée des mises en œuvres.

Conditions d'admission : Le Directeur lance un appel de mises en œuvre lorsqu'il estime que le groupe de travail a rempli les conditions générales de promotion.

Le groupe de travail N'EST PAS OBLIGÉ de présenter deux mises en œuvre indépendantes et interopérables du rapport technique avec la requête pour un appel de mises en œuvre adressée au Directeur. Toutefois, le groupe de travail DEVRAIT inclure dans la demande un rapport indiquant les mises en œuvre existantes et prévues.

Dans l'appel de mises en œuvre, le groupe de travail PEUT identifier des caractéristiques particulières du rapport technique comme étant des caractéristiques risquées. Les déclarations générales telle que Nous prévoyons de supprimer toute caractéristique non mise en œuvre sont irrecevables : le groupe de travail DOIT identifier précisément toutes les caractéristiques risquées. En réponse à un appel de mises en œuvre, un rapporteur peut donc indiquer s'il déposera ou non une objection formelle à la décision de supprimer les caractéristiques identifiées.

Après synthèse de l'expérience retirée des mises en œuvre, le groupe de travail PEUT supprimer du rapport technique les caractéristiques jugées risquées et demander au Directeur de lancer un appel à révision d'une recommandation proposée. Si le groupe de travail apporte d'autres changements importants au rapport technique, le Directeur DOIT le renvoyer au groupe de travail pour des travaux supplémentaires.

La demande adressée au Directeur de promouvoir un rapport technique au statut de recommandation candidate DOIT indiquer si le groupe de travail pense satisfaire, outre les conditions minimales (décrites ensuite), à certaines conditions d'admission du statut de recommandation proposée.

Les représentants au Comité consultatif PEUVENT faire appel de la décision de promouvoir le rapport technique.

Durée de la période de mise en œuvre : L'annonce DOIT indiquer une durée minimale, avant l'échéance de laquelle le groupe de travail NE DOIT PAS demander d'appel à révision d'une recommandation proposée ; cette durée minimale autorise un délai pour les commentaires. L'annonce DEVRAIT également inclure l'estimation du temps nécessaire prévu par le groupe de travail pour la synthèse des données de mise en œuvre.

Étapes suivantes possibles :

7.4.4 L'appel à révision d'une recommandation proposée

Degré de maturité du document : Recommandation proposée.

Annonce : Le Directeur DOIT annoncer l'appel à révision au Comité consultatif.

But : À ce stade, le W3C recherche l'approbation du rapport technique stable. Le résultat de cette révision est interprété comme une indication du soutien du rapport technique par l'organisation.

Conditions d'admission : Le Directeur lance l'appel à révision lorsqu'il estime que le groupe de travail a satisfait aux points suivants :

  1. Rempli les conditions générales de promotion ;
  2. Montré que chaque caractéristique du rapport technique a été mise en œuvre. De préférence, le groupe de travail DEVRAIT pouvoir démontrer deux mises en œuvre interopérables pour chaque caractéristique. Si le Directeur estime qu'une révision immédiate par le Comité consultatif est critique pour le succès d'un rapport technique, le Directeur PEUT accepter de lancer un appel à révision d'une recommandation proposée même sans expérience de mise en œuvre adéquate ;
  3. Satisfait toute autre condition d'admission annoncée (par exemple, une condition incluse dans la demande de promotion au statut de recommandation candidate ou bien annoncée en dernier appel si le groupe de travail n'a pas l'intention de demander un appel de mises en œuvre).

Les représentants au Comité consultatif PEUVENT faire appel de la décision de promouvoir le rapport technique.

Durée de la révision : L'annonce marque le début d'une période de révision qui DOIT durer au moins quatre semaines.

Poursuite des travaux : Pendant la période de révision, le groupe de travail demande l'approbation et le soutien des membres (par exemple, des témoignages pour un communiqué de presse).

Étapes suivantes possibles :

7.4.5 La publication d'une recommandation du W3C

Degré de maturité du document : Recommandation.

Annonce : Le Directeur DOIT annoncer la publication d'une recommandation du W3C au Comité consultatif.

But : Le W3C publie une recommandation dès lors qu'il estime que les idées contenues dans le rapport technique conviennent à une large diffusion et qu'elles promeuvent la mission du W3C.

Conditions d'admission : Le Directeur publie une recommandation du W3C lorsque le Comité consultatif, l'Équipe, les groupes de travail du W3C et le public manifestent un soutien significatif au rapport technique. La décision de promouvoir un document au statut de recommandation est une décision du W3C.

En cas de désaccord pendant la révision par les membres, les représentants au Comité consultatif PEUVENT faire appel de la décision de publier la recommandation.

Étapes suivantes possibles :

Le Directeur PEUT soumettre une recommandation du W3C à un autre organisme de normalisation pour son adoption et son homologation formelle.

7.4.6 Le renvoi du document au groupe de travail pour des travaux supplémentaires

Un rapport technique est renvoyé au groupe de travail pour des travaux supplémentaires dans l'une des situations suivantes :

  1. Le groupe de travail apporte des changements importants au rapport technique à tout moment compris après une annonce en dernier appel et avant la publication en tant que recommandation, sauf lorsque les changements concernent la suppression des caractéristiques risquées identifiées suite à un appel de mises en œuvre. En cas de changements importants, le groupe de travail DOIT republier le rapport technique au statut de version de travail ;
  2. Le Directeur demande au groupe de travail de traiter les problèmes importants signalés pendant une révision ou mis en lumière au cours de mises en œuvre. Auquel cas, le Directeur PEUT demander au groupe de travail de republier le rapport technique au statut de version de travail, même si celui-ci n'y a effectué aucun changement important.

Le Directeur DOIT informer le Comité consultatif et les présidents de groupe qu'un rapport technique a été renvoyé à un groupe de travail pour des travaux supplémentaires.

Après republication au statut de version de travail, le groupe de travail ne peut alors avancer qu'au travers d'une annonce en dernier appel. L'annonce en dernier appel PEUT survenir en même temps que la publication de la (nouvelle) version de travail.

Le Directeur PEUT demander au groupe de travail de republier un rapport technique au statut de recommandation candidate. Le Directeur lance un appel de mises en œuvre en même temps que la publication.

7.5 La fin des travaux sur un rapport technique

Les travaux sur un rapport technique PEUVENT cesser à n'importe quel moment. Lorsqu'un groupe de travail achève son travail sur un rapport technique, il le publie soit comme recommandation, soit comme note de groupe de travail. Par exemple, un groupe de travail peut publier plusieurs versions de travail d'un document des besoins et indiquer qu'il n'a plus l'intention de travailler sur ce document en publiant alors une note de groupe de travail.

Les travaux PEUVENT également cesser parce que le W3C estime improductive la poursuite des travaux. Par exemple, le Directeur peut clore le groupe de travail, les participants peuvent se désintéresser du rapport technique ou un autre rapport technique peut en reprendre les idées. Si le W3C décide d'arrêter les travaux sur un rapport technique avant son terme, alors le rapport technique DEVRAIT être publié en tant que note de groupe de travail.

Étapes suivantes possibles :

7.6 La modification d'une recommandation du W3C

Le W3C met tout en œuvre pour suivre ses recommandations (par exemple, en répertoriant les erreurs, en fournissant des applications bancs d'essai et en aidant à créer des ensembles de tests) et pour encourager une large mise en œuvre. Les sections suivantes traitent de la gestion des erreurs et du processus permettant d'apporter des changements normatifs à une recommandation.

7.6.1 La gestion des erreurs

Le dépistage des erreurs représente une partie importante du suivi d'une recommandation par le groupe de travail ; c'est la raison pour laquelle la charte d'un groupe définit généralement un délai pour les travaux suivant la publication d'une recommandation. Dans le présent Document de processus, le terme errata désigne toute classe d'erreur depuis une simple coquille jusqu'à une erreur pouvant influer sur la conformité des logiciels et des contenus avec la recommandation (par exemple, la validité du contenu). Remarque : Avant qu'un document ne devienne une recommandation, le processus du W3C se concentre sur les changements importants (ceux relatifs aux révisions précédentes). Après que le document a été publié en tant que recommandation, le processus du W3C se concentre sur les changements du rapport technique susceptibles d'influer sur la conformité des contenus ou des logiciels existants.

Les groupes de travail DOIVENT suivre les erreurs au travers d'une page d'erreurs. Une page d'erreurs est une liste d'erreurs numérotées, qui sont éventuellement accompagnées de corrections. Chaque recommandation contient un lien vers une page d'erreurs (cf. Les règles de publication de l'Équipe).

Une correction est d'abord proposée par le groupe de travail. Elle devient normative (c'est-à-dire, d'un statut égal à celui du texte dans la recommandation publiée) au travers de l'un des processus décrits plus loin. Une page d'erreurs PEUT contenir à la fois des corrections proposées et des corrections normatives. Le groupe de travail DOIT identifier clairement celles proposées et celles normatives.

Un groupe de travail DEVRAIT tenir ses pages d'erreurs à jour, au fur et à mesure où les lecteurs et les développeurs signalent des erreurs. Un groupe de travail DOIT signaler les changements des pages d'erreurs au tiers intéressés, notamment lorsque des corrections sont proposées ou deviennent normatives, conformément aux règles de l'Équipe. Par exemple, l'Équipe peut mettre en place une liste de diffusion pour une recommandation dont le groupe de travail signale les changements survenus sur la page d'erreurs.

7.6.2 Les classes de changements à une recommandation

Ce document distingue les classes de changements à une recommandation suivantes :

1. Aucun changement au contenu textuel
Ces changements comprennent la réparation des liens brisés ou d'un balisage invalide.
2. Les corrections qui n'influent pas sur la conformité
Des changements de rédaction ou des éclaircissements qui ne changent pas le contenu technique de la spécification.
3. Les corrections qui PEUVENT influer sur la conformité mais n'ajoutent aucune nouvelle caractéristique
Ces changements PEUVENT influer sur la conformité vis-à-vis de la recommandation. Un changement de ce type peut :
  1. Transformer des données ou des processeurs conformes, ou d'autres agents conformes, en agents non conformes ;
  2. Transformer des agents non conformes en agents qui le sont ;
  3. Dissiper une ambiguïté ou une partie imprécise de la spécification de sorte qu'un agent, dont la conformité était mal établie au premier chef, devienne clairement conforme ou bien non conforme.
4. Les nouvelles caractéristiques

Les deux premières classes de changements n'ont besoin d'aucune validation technique des changements proposés, quoique le groupe de travail PUISSE publier un appel à révision. La recommandation modifiée est publiée conformément aux règles de l'Équipe, y compris Les règles de publication [PUB31].

Pour la troisième classe de changements, le W3C impose :

  1. Une révision par la communauté afin d'assurer la validité technique des corrections proposées ;
  2. Une publication rapide de la recommandation éditée, en y incorporant les corrections.

Pour la troisième classe de changements, le groupe de travail DOIT :

  1. Soit demander au Directeur de publier un appel à révision d'une recommandation éditée ;
  2. Soit publier un appel à révision des corrections proposées, les corrections n'étant pas incorporées dans une version éditée (par exemple, celles listées dans la page d'erreurs). Après révision, le Directeur PEUT annoncer que les corrections proposées deviennent normatives.

Alors que la deuxième approche permet à un groupe de travail d'établir rapidement des corrections normatives, cela n'empêche pas qu'il faille incorporer les changements à une version éditée de la recommandation. En particulier, quand les corrections sont nombreuses ou complexes, leur présentation en un seul document est importante pour l'interopérabilité, sinon les lecteurs risquent de mal interpréter les corrections.

Pour la quatrième classe de changements (nouvelles caractéristiques), le W3C DOIT suivre le processus complet de promotion d'un rapport technique vers la recommandation.

7.6.3 L'appel à révision d'une recommandation éditée

Degré de maturité du document : Recommandation éditée proposée.

Annonce : Le Directeur DOIT annoncer l'appel à révision aux autres groupes du W3C, au public et au Comité consultatif. L'annonce DOIT clairement indiquer qu'il s'agit d'une proposition afin d'éditer une recommandation et elle DOIT:

  1. Indiquer la date limite pour le dépôt des commentaires de révision ;
  2. Identifier les dépendances connues et solliciter une révision par tous les groupes dépendants ;
  3. Solliciter une révision par le public.

But : À ce stade, le W3C recherche une confirmation des corrections proposées pour la recommandation.

Conditions d'admission : Le Directeur lance un appel à révision lorsqu'il estime que le groupe de travail a rempli, en ce qui concerne les changements au document, les mêmes conditions d'admission que pour un appel à révision d'une recommandation proposée (par exemple, le groupe de travail peut montrer une expérience de mise en œuvre qui tient compte des changements). Dans la requête de promotion à ce statut, le groupe de travail DOIT signaler tous les problèmes importants non résolus concernant le rapport technique.

Les représentants au Comité consultatif PEUVENT faire appel de la décision de promouvoir le rapport technique.

Durée de la révision : L'annonce marque le début d'une période de révision formelle par le Comité consultatif qui DOIT durer au moins quatre semaines.

Poursuite des travaux : Pendant la période de révision, le groupe de travail sollicite et répond aux commentaires de l'Équipe, des membres, des autres groupes du W3C et du public.

Étapes suivantes possibles :

7.6.4 L'appel à révision des corrections proposées

Degré de maturité du document : Une recommandation avec une liste de corrections proposées. Le groupe de travail DEVRAIT également inclure une description détaillée de la façon prévue de changer le texte de la recommandation pour chaque correction proposée.

Annonce : Le groupe de travail DOIT annoncer l'appel à révision aux autres groupes du W3C, au public et au Comité consultatif. Ce n'est pas une révision formelle par le Comité consultatif. Par contre, l'annonce DOIT indiquer clairement qu'il s'agit d'une proposition afin d'apporter des corrections normatives à la recommandation et elle DOIT :

  1. Indiquer la date limite pour le dépôt des commentaires de révision ;
  2. Identifier les dépendances connues et solliciter une révision par tous les groupes dépendants ;
  3. Solliciter une révision par le public.

But : À ce stade, le W3C recherche une confirmation des corrections proposées pour la recommandation.

Conditions d'admission : Le groupe de travail lance un appel à révision lorsqu'il estime avoir rempli, en ce qui concerne les changements au document, les mêmes conditions d'admission que pour un appel à révision d'une recommandation proposée.

Durée de la révision : L'annonce marque le début d'une période de révision qui DOIT durer au moins quatre semaines.

Poursuite des travaux : Même chose que pour une recommandation éditée proposée.

S'il n'y a aucune objection formelle aux corrections proposées, le W3C les considère alors comme normatives. Le groupe de travail DOIT signaler les objections formelles au Directeur qui évalue le consensus et, s'il est suffisant, déclare les corrections proposées comme étant normatives.

Étapes suivantes possibles :

7.7 L'abrogation d'une recommandation du W3C

Le W3C PEUT parfois abroger une recommandation entière, par exemple, lorsqu'il a connaissance d'erreurs importantes dans la recommandation, lorsque la recommandation devient obsolète ou si le W3C découvre que des droits de brevets pénalisants affectent les développeurs (cf. La politique de brevets du W3C [PUB33], et particulièrement la section 5 (article 10) et la section 7.5.

Pour désavouer des parties d'une recommandation, le W3C suit le processus de modification d'une recommandation.

Dès lors que le W3C a abrogé une recommandation, les rapports techniques ultérieurs du W3C NE DOIVENT PLUS contenir de référence normative à ce document.

7.7.1 La proposition d'abroger une recommandation

Degré de maturité du document : Recommandation avec les justifications séparées de la proposition d'abroger.

Annonce : Le Directeur DOIT annoncer la proposition d'abroger une recommandation aux autres groupes du W3C, au public et au Comité consultatif. L'annonce DOIT indiquer clairement qu'il s'agit d'une proposition afin d'abroger une recommandation et elle DOIT :

  1. Indiquer la date limite pour le dépôt des commentaires de révision ;
  2. Identifier les dépendances connues et solliciter une révision par tous les groupes dépendants ;
  3. Solliciter une révision par le public.

But : À ce stade, le W3C recherche une confirmation de la proposition d'abroger une recommandation.

Conditions d'admission : Le Directeur propose que le W3C abroge une recommandation lorsqu'il estime que les raisons de le faire sont suffisantes.

Les représentants au Comité consultatif PEUVENT faire appel de la proposition d'abroger la recommandation.

Durée de la révision : L'annonce marque le début d'une période de révision qui DOIT durer au moins quatre semaines.

Poursuite des travaux : Pendant la période de révision, le groupe de travail sollicite et répond aux commentaires de l'Équipe, des membre, des autres groupes du W3C et du public.

Étapes suivantes possibles :

7.7.2 La publication d'une recommandation abrogée

Degré de maturité du document : Recommandation abrogée.

Annonce : Le Directeur DOIT annoncer la publication d'une recommandation abrogée au Comité consultatif.

But : À ce stade, le W3C indique qu'il désavoue désormais une recommandation publiée précédemmment.

Conditions d'admission : Le Directeur publie une recommandation abrogée lorsqu'il estime qu'un soutien significatif en ce sens existe au sein du Comité consultatif, de l'Équipe, des groupes du W3C et du public. La décision de promouvoir un document au statut de recommandation abrogée est une décision du W3C.

L'Équipe PEUT publier un ou plusieurs documents afin de préciser ce qui a été abrogé relativement à des recommandations précédentes (par exemple, la publication peut simplement prendre la forme d'une feuille de couverture indiquant une recommandation publiée précédemment).

En cas de désaccord pendant la révision de la recommandation abrogée proposée, les représentants au Comité consultatif PEUVENT faire appel de la décision d'abroger la recommandation.

Étape suivante possible :

7.8 Les informations générales à propos des rapports techniques

Chaque document publié dans le cadre du processus de développement des rapports techniques DOIT rester public. Le W3C met à disposition un index des rapports techniques du W3C [PUB11] sur son site Web. Le W3C mettra tout en œuvre pour assurer indéfiniment la disponibilité des documents à leur adresse et dans leur forme originales.

Chaque document publié dans le cadre du processus de développement des rapports techniques DOIT mentionner clairement son degré de maturité.

Chaque document publié dans ce cadre est rédigé par un ou plusieurs rédacteurs nommés par le président du groupe. Les rédacteurs doivent s'assurer que les versions successives du rapport technique reflètent fidèlement les décisions du groupe. Un rédacteur agissant pour le compte du Groupe d'architecture technique ou du Conseil consultatif, participant au groupe sans y être élu ou nommé, DOIT satisfaire aux mêmes conditions de participation du groupe que celles d'un représentant de membre, d'un représentant de l'Équipe ou d'un expert invité. Tous les autres rédacteurs sous l'égide du W3C DOIVENT être des participants au groupe responsable du (ou des) document(s) à rédiger. Remarquez qu'un rédacteur N'EST PAS OBLIGÉ d'être un représentant de l'Équipe.

L'Équipe N'EST PAS TENUE de publier un rapport technique non conforme à ses règles de publication (par exemple, la dénomination, le style et les règles de protection des documents). Ces règles peuvent changer. L'Équipe DOIT informer les présidents de groupe et le Conseil consultatif de tous changements.

L'Équipe se réserve le droit de reformater à tout instant les rapports techniques pour les conformer à l'évolution des pratiques du W3C (par exemple, les changements de styles des rapports techniques ou de la section de statut du document).

L'anglais est la langue primaire des rapports technique du W3C. Le W3C encourage la traduction de ses rapports techniques. On trouvera des renseignements pour la traduction des rapports techniques du W3C [PUB18] sur le site Web du W3C.

7.8.1 La section de statut du document

Chaque rapport technique DOIT inclure une section sur le statut du document. La section de statut DEVRAIT expliquer pourquoi le W3C a publié le rapport technique, quelles sont les attentes pour les étapes à suivre, qui sont les développeurs, où envoyer les remarques au sujet du document, si une expérience de mise en œuvre est demandée, tous les changements importants depuis la version précédente, pourquoi les travaux sur le rapport technique ont cessé ou ont été repris et toutes autres informations pertinentes ou justifications.

Les règles de publication de l'Équipe comprennent des obligations de section de statut pour chaque degré de maturité.