摘要

  • RFC 出版中心的可选 GitHub 最终审稿，以获准进入出版队列的源文件为基准，在拉取请求中展示编辑修改。10 月月报于 2026 年 9 月 30 日发出；报告当时记录 31 份队列文件的作者同意参与，试点每月接五份。
  • 官方路线图规定，问题解决后合并拉取请求，但作者对最终文件的批准仍通过邮件给出；随后源文件被复制进出版中心的文件系统。PR 记录编辑决定，邮件记录授权，复制后的文件成为出版输入。公开路线图没有说明用同一个版本指纹贯穿三步。

红笔留下了差异记录

一份技术文稿通过标准流程，离成为 RFC 还差出版编辑和作者终审。过去，作者往往要在互传的文件中核对改动。RFC 出版中心的 2026 年 10 月月报于 9 月 30 日发出，介绍了一个可选试点：编辑把拟议改动放到 GitHub 拉取请求中。官方路线图把操作写得很细：先给获准的源文件建立文档仓库和基准分支，再开一条拟议修改分支；作者能对着差异逐句审看，问题留在评论或仓库事项里。

这样的可见性有实际价值。一处术语是否全篇统一，不用靠读者猜编辑在哪些附件里动过手。小改动可直接给出建议，大改动可在评论中说明，再由编辑提交到分支。问题解决，PR 合并。但路线图下一句很重要：作者仍需通过邮件批准最终文件。合并按钮证明编辑讨论告一段落，邮件才是作者对定稿点头的地方。

试点入口也有限。月报说每月只接五份文件；截至 9 月 30 日，队列里已有 31 份文件的作者同意参加，10 月还可接五份。31 是当时的参与意愿数量，五是月度入场上限。报告没有公布每份文件的进入顺序、等待起点、10 月完成量。把 31 除以五，算出一个“预计等六个月”，会把报名队列误当成已经排好的服务队列。能确定的是：愿意尝试的人数超过一个月的试点容量。

同一份报告还写了另一项五份/月的试点：接受 kramdown-rfc 作为源文件格式，当时这类文档有 23 份在队列。那是输入格式的试验；GitHub 项目试的是终审沟通方式。两组是否重叠，报告没给。把 23 与 31 相加，既不能算参加人数，也不能算积压量。

合并之后，信封才到

路线图的初始阶段从“获准进入出版队列的源文件”开始。编辑改动在独立分支上，PR 供作者审阅；问题解决后合并。若作者要提出超出编辑改动的更新，需要另开 PR，涉及实质变化时还可能由对应标准流负责人通过邮件批准。这个分界保护的是审批对象：润色同一句话与追加一项新规范，不能用同一套手势带过。

作者最终邮件批准之后，出版中心把源文件复制回自身文件系统，完成后续出版。这里出现了三个保管位置：仓库里记录“改了什么”，邮件里记录“同意了什么”，出版系统里保存“交给读者什么”。假如作者看到的最后一版与复制出去的文件相同，版本链就能闭合。官方路线图没有写明这三处是否都记录同一个提交号或哈希。缺少公开说明，不等于已经发生版本错配；它指出了试点应该回答的核对问题。

对于 kramdown-rfc，转换成 RFCXML 后还要再开一个 PR，让作者看格式转换带来的变化。原文内容能保持不动，最终排版却可能改变；第二次差异审查便有独立意义。若邮箱中的最终批准指向某个版本，出版中心需要知道它覆盖了内容校订和格式转换后的哪一份文件。

路线图往后还规划私有的内部仓库、编辑分支和出版自动化，并说明作者批准与 IANA 操作由队列管理系统 Purple 处理，而非交给 GitHub Actions。部分要求仍标“进行中”或“待办”，作者直接在 GitHub 协作属于更后面的阶段。不能把路线图当成所有步骤已部署的证明；当前月报足以确认的是可选终审试点和月度上限。

五个位置够不够用

每月五份不是宏大数字，作为试验却能留下观察空间：一条评论何时结案，转换后的文件谁复查，批准邮件指向哪一版。月报说作者在文稿进入队列时通过表单选择是否参加，却没给 31 份已同意文稿的入场排序规则。下期报告若能分别列出同意、入场、完成审稿、完成出版四类数量，外界才能判断小上限是审慎试运行，还是让愿意尝试的作者长期等在门口。

不参加的人仍可沿原有邮件流程做最终审稿。出版中心还在研究把编辑改动回写给作者自身仓库的办法。若这一步实现，作者继续维护的源文件就不会在出版后默默落后于读者看到的定稿。