要約

  • RFC Production Centerの任意参加の最終レビュー試行では、承認済み原稿から編集案のブランチとプルリクエストを作る。2026年9月30日に送られた報告は、参加に同意した著者の文書31件と月5件の受け入れ枠を記録した。現在の待ち時間を示す数字ではない。
  • 公式ロードマップでは、編集上の問題を解消してPRをマージした後も、文書への著者の最終承認はメールで受ける。完成した原稿は出版のためセンターのファイルシステムにコピーされる。差分、承認、出版入力を結ぶ版識別子は公開手順に明記されていない。

赤字を比較できるようにする

技術的な審査を終えた文書は、それだけでRFCとして印刷されるわけではない。編集者が体裁や記述を整え、著者が最終稿を確認する。RFC Production Centerの2026年10月報告は、この最後の確認でGitHubを選べる試行を説明する。センターのロードマップによると、出版キューに入った承認済みの元ファイルを文書用リポジトリに置き、編集案を別ブランチに載せ、PRで著者に示す。著者は行ごとに変更を見て、提案や質問を残せる。

ここで改善されるのは、修正の所在だ。添付ファイルを何度も送り返すと、どの句読点を誰が変えたか追いにくい。PRなら元の行と修正行が並び、全体の用語統一のような大きい問題もコメントやissueで扱える。問題がなくなればPRをマージする。だがそのボタンが著者の最終承認になるとはロードマップに書かれていない。文書への最後の「はい」はメールで届ける。

試行には入場制限がある。センターは月5件を受け入れるとしていた。9月30日に送られた報告では、キューにある31件の文書について著者が参加に同意し、10月に受け入れ可能なのは5件だった。31件はその日の同意件数、5件は月間の上限である。受付順、各文書の待ち始めた日、10月中に完了した件数は示されていない。単純な割り算で待ち月数を出すには材料が足りない。ただ、希望者がひと月の枠を上回っていたことは分かる。

同じ報告は、kramdown-rfcを原稿形式として受け入れる別の試行も月5件とし、その形式の文書が23件キューにあると記す。これは入力形式の試行で、GitHubによる最終レビューとは別の数だ。両方に該当する文書の数は公表されていない。二つの列を足して一つの滞留件数とすることもできない。

マージの後に残る封筒

ロードマップの初期段階は、技術的に承認されたソースをapprovedブランチに置く。センターが提案する修正はproposed-editsブランチに載り、PRとして議論される。著者が編集と無関係の変更を望む場合には別のPRが必要で、内容次第ではストリーム管理者のメール承認も要る。この区別は、編集者の言い換えと技術的な内容の追加を同じ承認の下に紛れ込ませないために意味がある。

編集上の問題が解消されてPRがマージされると、著者は最終文書をメールで承認する。センターはその後、完成したソースを自分たちのファイルシステムにコピーして出版作業を続ける。PRには変更の履歴があり、メールには著者の意思があり、コピー先には出版に使うファイルがある。それぞれが別の証拠だ。ロードマップはこの三者に同一のコミット番号やハッシュを記載する手順までは説明していない。ここで問うのは確認方法であって、実際に承認と異なるRFCが出たという主張ではない。

kramdown-rfcのソースなら、RFCXMLへの変換後にもう一つPRを作り、形式がどう変わったか著者に見せるという。文章が同じでも表示形式や構造が変わることはある。最終メールがどの版を承認したのか、変換後の確認と出版用のファイルまで追えるようにする必要がある。

ロードマップには、その先の社内向け非公開リポジトリ、編集者間のPR、出版作業の自動化も載る。著者承認とIANAの作業はGitHub ActionsではなくPurpleというキュー管理システムで扱う構想だ。各段階には進行中や未着手の要件が残る。現在の報告が裏付けるのは任意参加のレビュー試行と月5件の枠であり、将来構想をすでに完成した設備として語ることはできない。

5件の枠の使い道

小さな枠には意味がある。差分への返信、著者のメール、形式変換、ファイルの引き渡しがどこで噛み合わなくなるかを、センターが文書ごとに確かめられるからだ。だが31件の希望者がいるなら、選び方も説明できる方がよい。報告は著者に入稿時のフォームで参加希望を尋ねるとするが、誰を先に選ぶかの公開規則はない。次の報告で同意件数、受け入れ件数、レビュー完了件数、出版件数を分ければ、試行がどこまで進んだか見える。

メールによる従来の最終レビューは引き続き利用できる。センターはまた、編集済みの変更を著者自身のリポジトリに持ち帰る支援を検討している。出版後も著者の作業用原稿だけが古い表現を抱えることを減らす、地味だが役に立つ構想だ。