Resumen

  • El piloto opcional de Revisión Final del Centro de Producción de RFC muestra los cambios propuestos en una solicitud de incorporación abierta contra el archivo fuente aprobado. El informe del 30 de septiembre de 2026 decía que había 31 documentos con autores interesados y un límite de cinco admisiones al mes. Es una fotografía fechada, no un plazo de espera para octubre.
  • La hoja de ruta conserva la aprobación final del autor por correo y la copia del archivo al sistema del Centro para publicarlo. Fusionar el pull request registra la resolución editorial; no sustituye el consentimiento de quien firma el texto ni identifica por sí solo el archivo que termina publicado.

El lápiz rojo encuentra una línea de código

La etapa final de un RFC no consiste en cambiar una palabra a escondidas. El Centro de Producción lo prepara para publicación y sus autores comprueban las correcciones. Según el informe oficial remitido al grupo de la serie RFC, la vía experimental permite enseñar esas correcciones como un pull request de GitHub. La hoja de ruta del propio Centro explica que toma el archivo fuente aprobado, crea un repositorio documental y abre una rama de cambios propuestos. En la comparación, el autor puede ver qué frase se tachó, cuál la reemplaza y qué pregunta queda abierta.

El cambio práctico es la discusión pegada al texto. Una sugerencia breve puede aceptarse allí mismo; una corrección terminológica amplia puede describirse en comentarios o incidencias y ser incorporada por el equipo editorial. Cuando no quedan cuestiones pendientes, se fusiona la solicitud. Después llega un paso de otro tipo: los autores entregan su aprobación final del documento mediante correo electrónico. La hoja de ruta no confunde la reunión de versiones con la autorización personal.

El Centro probaba esa ruta con cinco documentos nuevos al mes. Su informe enviado el 30 de septiembre indicaba que los autores de 31 documentos en la cola ya habían aceptado participar; octubre tenía cinco plazas. Eso muestra interés superior a la capacidad mensual, pero no una espera de seis meses ni de ningún otro número: la fuente no revela orden de admisión, fechas individuales ni cuántos expedientes terminaron en octubre. Una cola puede crecer aunque el servicio acelere, y también puede disminuir por razones que no aparecen en esta fotografía.

El mismo informe habla de otro experimento: aceptar archivos kramdown-rfc como formato de entrada, también con un máximo de cinco por mes. En esa cola se contaban 23 documentos. El formato de origen y el canal de revisión final son decisiones diferentes, y el reporte no dice cuántos documentos figuran en ambas cifras. Los 31 no se suman a los 23 para fabricar 54 solicitantes de un único servicio.

Tres lugares para un mismo documento

El primer lugar es la rama que guarda el archivo aprobado al entrar en la cola. El segundo es el pull request con las modificaciones que el Centro propone. El tercero no está en GitHub: el correo donde el autor da su aprobación final. Tras esa aprobación, el Centro copia el archivo fuente a su sistema de ficheros para los pasos de publicación. El recorrido tiene sentido operativo, pero exige poder identificar qué revisión concreta cruza cada puerta.

Supongamos que una frase cambia después de una primera ronda de comentarios. El historial del pull request puede enseñar la nueva frase; el correo tendría que referirse a la versión que el autor vio, y el archivo copiado debería contener precisamente esa versión. La hoja de ruta pública no especifica un identificador o suma de comprobación compartido en los tres registros. Esa ausencia de descripción plantea una prueba para el piloto; no demuestra que se haya publicado un RFC distinto del aprobado.

Si la fuente usa kramdown-rfc, la hoja de ruta añade otra revisión después de convertirla a RFCXML. El Centro abre un segundo pull request para que el autor vea cambios de formato. Una palabra puede conservarse mientras cambia su presentación; por eso la revisión de la conversión tiene un objeto distinto de la revisión de contenido. La aprobación final debería poder vincularse al archivo que sale de ambas.

La hoja de ruta también dibuja fases posteriores con repositorios internos privados y herramientas de publicación. En la primera fase interna, las aprobaciones de autores y actuaciones de IANA quedan en Purple, el sistema de gestión de la cola, no en acciones de GitHub. La colaboración directa posterior con autores figura aún como tarea futura. Esas páginas describen dirección y requisitos pendientes; el informe de septiembre es el documento que confirma el piloto opcional y su límite de entrada.

Una prueba con cinco asientos

El límite pequeño concede tiempo para descubrir dónde se pierde contexto al pasar de un comentario a una aprobación. También crea una obligación sencilla de información. El informe dice que el Centro pregunta a los autores por el piloto mediante un formulario de ingreso, pero no publica el criterio de elección entre los 31 interesados. Un próximo reporte útil separaría documentos que se ofrecen, que entran, que completan revisión y que salen publicados. Las cifras actuales solo permiten ver la boca de la cola.

Quien prefiera el método anterior mantiene la Revisión Final por correo. Además, el Centro estudia cómo devolver las correcciones al repositorio de trabajo de cada autor. Esa tarea evitaría que el texto publicado y la copia con la que el autor sigue trabajando se separen silenciosamente después de la edición.