Resumo

  • O piloto opcional de Revisão Final usa um repositório com o arquivo-fonte aprovado, uma ramificação de edições propostas e um pull request para os autores inspecionarem as mudanças. O relatório de 30 de setembro de 2026 contou 31 documentos com autores interessados e um teto de cinco admissões por mês, números daquele momento.
  • O roteiro oficial diz que o pull request é integrado quando as questões são resolvidas; o autor aprova o documento final por e-mail e o Centro copia a fonte para seu sistema de arquivos antes de publicar. O roteiro não descreve um identificador de versão único compartilhado por essas três evidências.

O lápis vermelho entra no histórico

Um documento aprovado para seguir rumo a RFC ainda passa pelas mãos dos editores de produção. Eles ajustam texto, referências e apresentação; os autores conferem o resultado antes da publicação. O relatório de outubro do Centro de Produção de RFC, enviado no fim de setembro, descreve um teste voluntário de Revisão Final no GitHub. Segundo o roteiro publicado pelo Centro, o arquivo aprovado ocupa uma ramificação de referência e as edições propostas aparecem em outra. O pedido de integração mostra a diferença entre ambas.

Esse detalhe muda o trabalho do autor. Uma vírgula pode ser discutida no trecho em que aparece; uma troca de termo em todo o documento pode virar comentário ou questão acompanhada pelos editores. Quando não há pendências, o pull request é integrado. O sim definitivo do autor, porém, continua sendo enviado por e-mail. O registro de uma edição e a autorização de quem assina o texto têm funções distintas no procedimento do próprio Centro.

O teste aceita cinco novos documentos por mês. Na fotografia do relatório enviado em 30 de setembro, havia 31 documentos na fila cujos autores já concordaram em participar, e outubro tinha espaço para cinco. Esses números não autorizam uma previsão do tempo de espera. Falta a ordem de entrada, a data em que cada documento ficou pronto para a revisão e o total efetivamente concluído no mês. O dado seguro é o contraste entre vontade de participar e capacidade de admissão de uma única rodada mensal.

O relatório traz outra contagem, próxima o suficiente para gerar confusão: 23 documentos kramdown-rfc na fila, também com limite de cinco admissões em outubro. Ali se testa o formato do arquivo recebido; no piloto GitHub se testa a conversa sobre a versão final. O relatório não apresenta o cruzamento entre os dois grupos. Nenhum leitor deve transformar 31 mais 23 numa fila única de 54 documentos.

Depois do merge, quem assina?

No roteiro de fase inicial, o Centro cria manualmente um repositório por documento quando começa a revisão final. A fonte que entrou na fila é preservada; a equipe abre uma ramificação de alterações e um pull request. As perguntas ao autor podem ficar em questões do repositório. Se o autor pedir mudanças além do trabalho editorial, precisa criar pedido próprio e, conforme o conteúdo, obter autorização do responsável pelo fluxo de publicação por e-mail. Essa barreira impede que uma revisão de redação vire uma alteração técnica sem passar por quem tem autoridade para ela.

Encerradas as pendências, o pull request é integrado. O autor então aprova por e-mail o documento final. O Centro copia a fonte aprovada para seu sistema de arquivos e conclui a publicação. Uma mudança tardia pode aparecer em um commit, ser mencionada em uma mensagem e chegar a um arquivo; a cadeia só é verificável se os três apontarem para a mesma revisão. O roteiro público não informa um hash ou identificador obrigatório atravessando os três lugares. Falta uma descrição da ligação, não uma prova de que algum RFC tenha saído diferente do que seu autor aprovou.

Para arquivos kramdown-rfc, o Centro prevê ainda um segundo pull request depois da conversão para RFCXML, de modo que o autor confira mudanças de formatação. O conteúdo de uma frase pode permanecer enquanto sua aparência ou estrutura muda. A revisão extra reconhece esse risco concreto; resta vincular sua versão final ao e-mail e ao arquivo publicado.

Fases posteriores do roteiro tratam de repositórios internos privados e de ações para gerar formatos e distribuir dados. O próprio texto mantém as aprovações dos autores e as ações de IANA sob Purple, o gestor da fila, e marca colaboração direta mais ampla como trabalho futuro. O roteiro descreve etapas em construção; o relatório confirma o piloto opcional que está sendo oferecido. Misturá-los produziria uma automação que ainda não foi demonstrada.

Cinco vagas para aprender

O limite modesto pode dar aos editores tempo para testar cada transferência de responsabilidade. Também exige uma medida melhor que a fila total. O Centro pergunta aos autores sobre a opção no formulário de entrada, mas não publica como escolhe entre os 31 que haviam aceitado ao fim de setembro. Um próximo relatório pode separar os convites aceitos, os documentos admitidos, as revisões concluídas e os RFCs publicados nessa rota. Só então o piloto mostrará sua velocidade real.

O caminho habitual por e-mail continua disponível aos autores que não participam. O Centro ainda estuda como devolver as correções aos repositórios próprios dos autores. A ideia é simples: quem continua trabalhando no texto não deveria guardar uma versão anterior à que o público consulta.