Summary

  • The RFC Production Center’s optional GitHub Final Review pilot starts from the approved source file, proposes edits in a pull request and resolves questions there. Its 30 September 2026 report counted 31 queued documents whose authors had opted in, against a limit of five admissions per month. Those figures are a dated snapshot, not a current wait-time calculation.
  • The official roadmap keeps final author approval in email and copies the final source back to the Center’s file system for publication. A merged pull request therefore records an editing decision, while a separate message authorizes the document and a separate handoff supplies publication. The public roadmap does not specify one revision identifier binding all three.

The red pen gets a diff

An author sends a document through standards review. The RFC Production Center edits it for publication. At the final review stage, the author must see what changed and say yes to the finished text. In the optional process described by the Center’s October 2026 report and its GitHub roadmap, the red pen now has a branch. The Center places the approved source file in a document repository, makes a proposed-edits branch, and opens a pull request. Authors can inspect a diff and discuss proposed wording where the change actually sits.

That is useful work. An edit buried in a mailed attachment is harder to follow than a line shown beside its earlier version. The roadmap permits suggestions inside the review and issue comments for larger terminology changes. The Center merges the pull request when issues are resolved. It still asks authors to give final approval of the document by email. The sequence is explicit. Nobody needs to pretend a green merge button is an author’s signature.

The report calls this an optional Final Review route. It says the Center was admitting five documents a month while testing the process. As of the report sent on 30 September, authors of 31 documents already in the queue had agreed to participate, and five could be accepted in October. Thirty-one is a count of opt-ins at that snapshot; five is a monthly pilot cap. The report does not publish the order in which those documents will enter the pilot, their arrival dates or October’s completed throughput. Dividing 31 by five would manufacture a waiting time from mismatched measurements.

The real observation is smaller and sharper: interest in the pilot exceeded one month of its available admission slots.

The same report separately counts 23 kramdown-rfc documents in the queue and a five-a-month cap for accepting that source format. Those are different pilots. A document could be relevant to both, but the report does not publish their overlap. The GitHub path concerns how the author reviews the Center’s edits; the kramdown path concerns which source format enters the editorial process. Counting them as one queue would turn two operational tests into a fictional bottleneck.

The envelope after the merge

The roadmap’s Phase 0 starts from a source file already approved for the RFC publication queue. That file goes on an approved branch; the Center’s changes appear on a proposed-edits branch. Questions can live in repository issues. Once review comments are settled, the pull request is merged. The authors then send final document approval by email. Finally the Center copies the source into its file system to complete publication. A PR, an email and a copied file are three different artifacts, each with a different custodian.

The difference matters most when a sentence changes late. A reviewer can point to the diff and say what was proposed. An author can point to an email and say what was approved. A publisher can point to the final source and say what was printed. If those records identify the same revision, the chain is easy to reconstruct. The public roadmap does not state that a single digest or revision ID is placed in all three. That omission identifies a question to ask of the pilot; it is not evidence that the Center has shipped a mismatched RFC.

For a kramdown-rfc source, the roadmap adds one more check. After the Markdown-based source is converted to RFCXML, the Center opens another pull request so authors can inspect formatting changes introduced by conversion. That second diff has an intelligible purpose: an approved sentence can still look different after a format transform. The final email and publication file still need to refer to the version the author actually reviewed.

The longer roadmap names an internal GitHub phase with private repositories and staff editing branches. It places author approvals and IANA actions in the Center’s Purple queue system rather than GitHub actions; later direct collaboration with authors is marked as future work. These are roadmap states, not proof that all private-repository and publication automation steps already run today. The optional Phase 0 described in the current report is the operating claim. The roadmap explains where the institution intends to take it.

The slow lane is deliberate

Five documents a month is an unglamorous pilot number. It gives editors time to discover what happens when a comment, a conversion and an email approval land in different tools. It also forces the Center to explain admissions. The report says authors opt in through an intake form, but it does not give a public selection rule among the 31 who had agreed by September’s end. That is a useful future metric: which documents enter, in what order, and at what revision do they leave the pilot for ordinary publication? An experiment should make its own queue legible before it becomes routine.

Authors who stay on the existing email route are still offered Final Review, according to the report. The new process changes the visibility of edits for participating authors. The Center is exploring backport support so they can carry those edits into their own repositories. That step, if implemented, would reduce a common nuisance: the author’s working source and the published source drifting apart after a round of editorial corrections.