Résumé

  • Dans le pilote facultatif du centre de production des RFC, les modifications proposées sont examinées dans une pull request ouverte à partir de la source approuvée. Le rapport envoyé le 30 septembre 2026 comptait 31 documents dont les auteurs avaient accepté de participer, alors que le centre en admettait cinq par mois. Ce décompte ne donne pas un délai d’attente actuel.
  • La feuille de route prévoit une fusion après résolution des questions, un accord final de l’auteur par courriel et une copie du fichier dans le système de publication. Le rapport entre ces trois versions est la question de contrôle : le document public ne décrit pas un identifiant commun qui relierait chaque étape.

Le stylo rouge devient une différence lisible

La production d’un RFC comporte une étape délicate après l’approbation technique. Les éditeurs préparent le texte à publier, et les auteurs vérifient une dernière fois les changements. Le rapport d’octobre du centre, envoyé le 30 septembre, décrit un essai facultatif : présenter les corrections dans une pull request GitHub plutôt que de faire porter toute la comparaison par des fichiers échangés. La feuille de route officielle précise la mécanique. La source approuvée est placée dans un dépôt documentaire ; une branche de corrections et sa demande de fusion exposent les changements ligne par ligne.

Le gain est très concret pour un auteur qui doit dire oui à des dizaines d’ajustements. Il voit la phrase ancienne à côté de la nouvelle, peut suggérer une modification et utiliser les questions du dépôt pour un problème plus large. Lorsque les points ouverts sont résolus, le centre fusionne la demande. Ce geste clôt le travail sur les corrections proposées. La feuille de route dit ensuite que l’auteur confirme le document final par courriel. L’autorisation personnelle n’a donc pas été déplacée sur le bouton de fusion.

Le centre limite le pilote à cinq documents admis chaque mois. Son rapport indique que, lors de l’envoi du 30 septembre, les auteurs de 31 documents déjà dans la file avaient donné leur accord pour participer et que cinq places pouvaient être prises en octobre. Ces chiffres montrent une demande supérieure à la capacité d’un mois. Ils ne donnent ni l’ordre d’entrée, ni le nombre de revues effectivement terminées en octobre, ni une date de sortie pour chacun des 31 dossiers. Transformer 31 divisé par cinq en attente annoncée serait donner une précision que la source ne possède pas.

Un second essai du même rapport accepte des sources kramdown-rfc, lui aussi à raison de cinq documents par mois ; 23 documents de ce type figuraient dans la file au même moment. Il s’agit d’un test de format, distinct du test de revue GitHub. On ignore combien de documents appartiennent aux deux groupes. Mélanger les deux nombres fabriquerait une seule queue imaginaire.

Après la fusion, une enveloppe

La séquence de la phase initiale est minutieuse. Le centre commence par le fichier approuvé pour entrer dans la file de publication et le place sur une branche de référence. Il prépare ses corrections sur une autre branche, ouvre la pull request, échange des commentaires et fusionne après résolution. Si l’auteur veut apporter des modifications étrangères au travail éditorial, une demande séparée peut être nécessaire ; selon leur portée, le responsable du flux peut devoir les approuver par courriel. Le système distingue ainsi correction éditoriale et changement de fond.

Une fois le document final accepté par l’auteur, le centre copie la source dans son système de fichiers pour terminer la publication. Cette copie est un passage de responsabilité. La branche dit ce qui a été édité ; le courriel dit ce qui a été accepté ; la source copiée détermine ce qui sera produit. Le texte de la feuille de route ne mentionne pas de numéro de révision ou d’empreinte unique reporté sur ces trois pièces. Cette lacune documentaire pose une question de vérification, sans établir qu’un RFC réel a déjà été publié avec une version non approuvée.

Le cas kramdown rend la question plus visible. La feuille de route prévoit, après conversion de cette source en RFCXML, une nouvelle pull request pour montrer les changements de mise en forme aux auteurs. Un accord sur les mots avant conversion ne décrit pas à lui seul l’apparence finale. La dernière approbation doit pouvoir être rapprochée du fichier que le centre copie, quelle que soit la forme qu’il a prise entre-temps.

La feuille de route poursuit avec des dépôts internes privés et d’autres automatisations. Elle réserve les approbations des auteurs et les opérations IANA à l’outil de gestion Purple, tandis qu’une collaboration plus directe avec les auteurs figure dans une phase future. Ces éléments annoncent des directions et des tâches encore en cours. Le rapport, lui, documente le pilote facultatif et son plafond mensuel ; c’est sur ce périmètre que l’on peut juger l’essai présent.

Cinq places, beaucoup de volontaires

Un petit plafond peut servir une expérience utile : les éditeurs découvrent les points où une correction, une question et un courriel ne se rejoignent pas facilement. Mais une file de volontaires demande aussi une règle d’admission intelligible. Le rapport dit que le centre propose l’option aux auteurs lors de l’entrée en production, par formulaire ; il ne publie pas de règle de sélection parmi les 31 accords reçus à la fin de septembre. Les prochains comptes rendus pourraient distinguer candidatures, entrées, revues terminées et publications. Une file n’est gouvernable que si l’on peut suivre ce qui y entre et ce qui en sort.

Les auteurs qui préfèrent le circuit de courriel gardent la revue finale, selon le rapport. Le centre envisage aussi un moyen de reporter ses corrections dans les dépôts personnels des auteurs. Si ce transfert se réalise, il évitera qu’une source de travail continue sa vie avec des erreurs déjà corrigées dans la version publiée.