Кратко

  • RFC Production Center проводит добровольное испытание финальной проверки через GitHub. Октябрьский отчет центра был отправлен 30 сентября 2026 года: на ту дату авторы 31 документа в очереди согласились участвовать, а предел приема составлял пять документов в месяц.
  • По официальной схеме редакторские изменения проходят через pull request; после разрешения вопросов его объединяют, затем автор дает финальное согласие по электронной почте, а окончательный исходный файл копируют в систему центра для публикации. В открытой схеме не названа единая метка версии для этих трех записей.

Подпись после кнопки Merge

Финальная проверка RFC выглядит скромнее обсуждения нового протокола, но именно здесь опубликованный текст получает последние исправления. Автору нужно увидеть, какие слова редактор заменил, и подтвердить итог. Октябрьский отчет RFC Production Center, разосланный 30 сентября, описывает необязательный опыт: редакторы показывают изменения в GitHub. Для тех, кто не участвует, сохраняется проверка по электронной почте.

Дорожная карта GitHub от самого центра разделяет роли инструментов. Центр вручную создает хранилище документа и помещает исходный материал, принятый в производство, в ветку approved. Предлагаемые редакторские исправления идут в другую ветку и pull request. Там видны различия и вопросы к отдельным местам. Когда вопросы решены, исправления объединяют. После этого автор все равно подтверждает окончательный документ письмом. Утвержденный исходник центр копирует в свою файловую систему для публикации.

Получается цепочка решений. Объединение изменений фиксирует решение редактора. Письмо фиксирует волю автора. Копия файла определяет материал, который пойдет читателю. Для проверки цепочки всем трем шагам нужен точный указатель на одну версию. Опубликованная схема не задает общей контрольной суммы или номера ревизии для PR, письма и скопированного файла. Именно такой связки не хватает открытому описанию процесса.

Очередь не равна сроку ожидания

Предел испытания — пять документов ежемесячно. На 30 сентября, по отчету центра, авторы 31 документа в очереди уже выразили согласие участвовать; в октябре центр мог принять пять. Пятерка — ограничение входа в опыт, а не число выпущенных RFC. Тридцать один — число документов с согласившимися авторами на дату отчета. Без порядка приема, новых заявок и числа завершений нельзя вычислить срок ожидания делением 31 на пять.

В том же отчете фигурирует 23: столько документов ожидали в другом испытании, посвященном входному формату kramdown-rfc. Его месячный предел тоже равен пяти. Совпадение цифры на табличке не объединяет две очереди. Отчет не указывает, сколько документов участвуют в обеих. Формат исходника и способ финальной проверки — разные предметы, и смешение счетчиков скрыло бы результат каждого опыта.

Небольшой набор может помочь центру обнаружить трения: где автор задает вопрос, когда редактор считает его закрытым, какая версия отправляется на согласие. Чтобы оценить это, следующему отчету понадобятся четыре числа по отдельности: согласившиеся, принятые, закончившие финальную проверку, опубликованные. Один счетчик у дверей не показывает работу цеха.

Вторая разница после преобразования

Для документов, пришедших в kramdown-rfc, дорожная карта предусматривает еще один pull request после преобразования в RFCXML. Он дает автору возможность просмотреть изменения представления. Это отдельный контроль: хороший редакторский diff до преобразования сам по себе не объяснит, как выглядит окончательный XML. Если в файле для публикации есть следствие конвертации, оно тоже должно попасть в тот же путь согласования.

Авторы могут захотеть поправок, не связанных с предложениями редактора. Для них дорожная карта требует отдельный pull request; в некоторых случаях потребуется согласие руководителя соответствующего потока по электронной почте. Так различаются исправление оформления и новое решение по содержанию. Эта граница важна при установлении того, кто имел право изменить утвержденный материал.

Следующие этапы дорожной карты включают закрытые внутренние хранилища и дополнительные действия перед публикацией. Согласия авторов и действия IANA там отнесены к производственной системе Purple, а не к автоматическим действиям GitHub. Более прямое участие авторов в GitHub пока записано как будущая работа. Наличие схемы будущего процесса не превращает все ее клетки в уже действующие функции.