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 :
annonce en dernier appelou l'
appel de mises en œuvre) ;
version de travailou
recommandation candidate). Veuillez remarquer qu'il n'y a pas forcément correspondance bi-univoque entre les étapes du processus de développement des rapports techniques et les degrés de maturité.
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.
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.
Outre les versions de travail visant la recommandation, les autres degrés de maturité du suivi de recommandation sont les suivants :
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
.
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.
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 :
Les informations suivantes sont importantes pour la décision de promotion d'un rapport technique et elles DOIVENT donc être rendues publiques :
diffsen plus des résumés des changements importants) ;
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.
L'expérience montre que les principes suivants facilitent l'apparition d'un consensus autour d'un rapport technique :
vied'un groupe de travail) ;
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.
Le W3C suit les étapes suivantes pour la promotion d'un rapport technique au statut de 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.
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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.
Un rapport technique est renvoyé au groupe de travail pour des travaux supplémentaires dans l'une des situations suivantes :
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.
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 :
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.
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.
Ce document distingue les classes de changements à une recommandation suivantes :
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 :
Pour la troisième classe de changements, le groupe de travail DOIT :
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.
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:
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 :
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 :
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 :
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.
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 :
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 :
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 :
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.
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é.