RFC и проектные документы: как выносить решение на обсуждение

Инженер пишет двенадцать страниц про переход платёжного сервиса на очередь. Диаграммы, бенчмарки, сравнение четырёх брокеров. Документ уходит в общий канал в пятницу вечером. К среде — сорок комментариев: тридцать два про именование полей в JSON, четыре про то, что «в схеме опечатка», три про «а зачем нам вообще микросервисы», один — от инженера из биллинга: «вы знаете, что мы читаем эту таблицу напрямую?» Этот один комментарий и был единственной причиной писать документ. Автор нашёл его в четверг, через три дня после того, как начал резать схему.

Другой вариант той же истории: документ пишется, когда код уже лежит в ветке. Комментарии приходят, автор вежливо отвечает «учтём в следующей итерации», через неделю ставится статус «согласовано». Все понимают, что происходит, но делают вид.

RFC — это не описание системы и не отчёт о проделанной работе. Это запрос на возражения, сделанный в момент, когда возражение ещё дешевле, чем переделка. Продукт RFC — не текст, а зафиксированное согласие и, что не менее ценно, зафиксированное несогласие с именами и причинами.

Из общего принципа трека — документ пишется под решение и под читателя («Читатель и решение») — для RFC следует предельно конкретное: решение звучит как «делаем ли мы это и в каком виде», читатель — тот, кто может это решение заблокировать или чью систему оно заденет. Всё, что не помогает ему возразить или согласиться, в документе лишнее.

Чем RFC отличается от соседних жанров

Слова в компаниях разные — RFC, RFD, дизайн-док, design proposal, one-pager, PEP, KEP, ТЗ, — но различаются не названия, а момент времени и направление документа.

Две пары путают чаще всего.

RFC и ADR. RFC отвечает на вопрос «что нам делать», ADR — «почему сделано так». Хороший процесс связывает их конвейером: RFC обсуждается, принимается и умирает, а из него выжимается ADR на полторы страницы, который ложится рядом с кодом и живёт годами. Если ADR у вас нет, RFC начинает притворяться вечным документом — и врёт про систему уже через квартал.

RFC и презентация. Презентация устроена так, чтобы возражений не возникло: слайд ведёт к выводу, спорные места — на словах, деталей нет. RFC устроен наоборот: он вытаскивает возражения наружу, пока они бесплатны. Автор, который выносит RFC, чтобы «утвердить», пишет презентацию в формате RFC — и получает ритуал, а не обсуждение.

Откуда взялся жанр

Название придумано в 1969 году от неуверенности. Стив Крокер, аспирант, писавший первую заметку про протоколы ARPANET, боялся, что документ прозвучит как указание старшим коллегам, и назвал его «Request for Comments» — запрос на комментарии (RFC 1; его собственный рассказ — в колонке для NYT). Скромность названия оказалась инженерным решением: она понижала цену чужого возражения и приглашала к правке, а не к подписи.

Полезное наблюдение: во всех живых процессах документ — не единственный артефакт. У Rust есть Final Comment Period и команда, принимающая решение (rust-lang/rfcs); у Kubernetes KEP привязан к релизу и стадиям alpha/beta/stable (kubernetes/enhancements); у Go есть комитет и цикл проверки (golang/proposal); у Python — статусы PEP (PEP 1). Компания, копирующая шаблон документа без срока, решающего и статуса, получает папку с текстами.

Когда открыто окно: раньше нельзя, позже бесполезно

Стоимость изменить решение растёт нелинейно. Пока решение живёт в голове, менять его бесплатно; после того как выбрана схема данных и подписан контракт API, цена растёт на порядок; после миграции данных — ещё на порядок.

• Слишком рано. Нет ни одного числа, ни одной проверенной гипотезы. Такой документ вызывает обсуждение вкусов, потому что обсуждать больше нечего. Лечится не текстом, а спайком на два дня: измерьте текущую задержку, посчитайте объём, попробуйте библиотеку.
• Окно. Вы уже знаете, какой вариант предпочитаете и почему, но ещё не написали кода, который жалко выбросить. Здесь возражение меняет проект, а не только текст, — ровно ради этого документ и пишется.
• Поздно. Код написан, миграция начата, сроки объявлены. Документ по-прежнему может быть полезен, но как ADR или как объявление о запуске, а не как RFC. Называть его RFC — способ приучить команду к тому, что комментарии ничего не решают.

Практический признак, что вы в окне: вы можете назвать факт, который заставил бы вас отказаться от собственного предложения. Если такого факта нет, вы не обсуждаете — вы объявляете.

Нужен ли документ вообще

Ветка «сделать и показать в PR» — не лень, а расчёт: обратимое решение дешевле проверить, чем обсудить. RFC оправдан там, где ошибка стоит недель: контракты между командами, схемы данных, выбор технологии, которую потом придётся эксплуатировать, изменения, ломающие обратную совместимость. Разбор самих архитектурных развилок — в треке «Архитектурные паттерны», а запись принятого решения — в «ADR».

Анатомия RFC: что в каждом разделе на самом деле решается

Шаблон не делает документ хорошим, но задаёт вопросы, которые автор иначе пропустит. Минимальный рабочий скелет — девять блоков; всё остальное добавляется по необходимости.

# RFC-042: <решение одной строкой, глагол + объект>

| Поле | Значение |
|---|---|
| Статус | Draft / Discussion / Accepted / Rejected / Superseded by RFC-051 |
| Автор | @имя |
| Решающий | @имя (владелец области) |
| Комментарии до | 2026-08-14 18:00 CET |
| Задевает | notifications-api, billing-worker, runbook RB-07 |

## Запрос на решение (3–5 строк)
Что предлагается, какое действие ждём от читателя, к какому сроку.

## Проблема
Числа и последствия, а не «текущее решение неудобно».

## Ограничения и не-цели
Что зафиксировано и не обсуждается в этом документе.

## Предложение
Как будет устроено. Схема, контракты, поведение при отказах.

## Альтернативы
Каждая — с ценой, с тем, что она чинит, и с условием, при котором она выигрывает.

## Влияние
Миграция, обратная совместимость, деньги, безопасность, эксплуатация, наблюдаемость.

## Открытые вопросы
Адресные вопросы конкретным людям, на которые нужен ответ до старта.

## План и откат
Этапы, критерий успеха, как откатываемся и до какого момента это возможно.

Пройдём по блокам, которые чаще всего пишут вхолостую.

Запрос на решение. Первые пять строк отвечают на вопрос «что от меня хотят». «Просим обратную связь» не запрашивает ничего: обратную связь можно дать эмодзи. Работают глаголы решения — одобрить вариант B, назвать блокирующее возражение, подтвердить, что ваша команда переживёт удаление колонки.

Проблема. Проверка, есть ли предмет. Без чисел и последствия документ превращается в спор вкусов: у каждого своё мнение о том, что «неудобно». Числа не обязаны быть точными, но обязаны быть измеримыми: раз в квартал, минут задержки, человеко-дней, инцидентов.

Ограничения и не-цели. Самый недооценённый раздел и главное средство против расползания обсуждения. «Смену языка сервиса и формат внешнего API этот документ не трогает» — одна строка, экономящая неделю. Работает, только если честна: объявив не-целью то, что документ на самом деле решает, вы получите то же обсуждение, но в личке и с обидой.

Альтернативы. Раздел существует не ради полноты, а чтобы снять возражение до того, как оно прозвучит: у каждого варианта — цена и условие победы. Обязателен вариант «ничего не делать»; его отсутствие выдаёт документ, написанный ради обоснования уже принятого решения.

Влияние. Единственная причина, по которой соседние команды вообще читают ваш документ. Не «влияние на систему», а адресно: чья схема меняется, чей раннбук устареет, кто платит, какие данные пересекают границу; нефункциональные требования — на языке, принятом у вас (таксономия — в «Нефункциональных требованиях»).

Открытые вопросы. Единственный раздел, отличающий RFC от объявления: автор показывает, что всерьёз не знает ответа и готов его получить.

План и откат. Точка, где предложение становится обязательством: этапы, критерий успеха, момент невозврата. Без критерия успеха вы через полгода не скажете, сработало ли, — и следующий такой же RFC придётся обсуждать с нуля.

Один и тот же текст, две версии

Примеры на английском, потому что в проде документы чаще пишут на нём; разбор — по-русски.

Пара 1: заголовок и запрос на решение

Как пишут обычно:

RFC-042: Notifications Rework

This RFC proposes a rework of the notification subsystem. The current implementation
has grown organically and has several issues. We would like to gather feedback from
the team on the proposed approach. Please share your thoughts.

Что здесь не работает: заголовок не называет решение — «rework» может означать что угодно, от смены библиотеки до переписывания на другом языке. «Grown organically» и «several issues» — эвфемизмы вместо фактов; читатель не может оценить, стоит ли тратить час. «Gather feedback» и «share your thoughts» не запрашивают решения и не называют срока, поэтому и приходят мысли, а не решения. Наконец, нет ни одного имени: непонятно, кто решает и кого это заденет.

Переписано:

RFC-042: Move notification delivery from in-process cron to a queue

Decision requested: approve Option B (SQS + worker) or name a blocking objection,
by Thu 2026-08-14 18:00 CET. Decider: @maria, owner of platform.

Why now: the cron job holds the request thread. On 2026-07-19 a 40-minute backlog
delayed 9,300 password-reset e-mails past their 15-minute TTL (INC-1183). Two more
releases on the current design and billing starts depending on the same retry table.

Blast radius: notifications-api, billing-worker (shares the `notifications` table),
on-call runbook RB-07.

Изменилось не качество прозы, а количество опор для решения: заголовок называет развилку (cron против очереди), запрос называет действие, срок и решающего, проблема даёт четыре числа и номер инцидента, «blast radius» сразу говорит трём командам, их ли это документ. Читатель из биллинга видит своё имя в четвёртой строке, а не на восьмой странице.

Пара 2: альтернативы

Как пишут обычно:

Alternatives considered

- Option A: Keep cron. Rejected, not scalable.
- Option C: Kafka. Rejected, too complex for our needs.
- Option D: Third-party provider. Rejected, expensive.

Три ярлыка вместо трёх сравнений. «Not scalable», «too complex», «expensive» — оценки без шкалы: непонятно, во сколько раз и по сравнению с чем. Главное — такой раздел не выполняет свою работу: инженер, который считает Kafka правильным выбором, не увидел, что его вариант рассмотрели всерьёз, и придёт спорить в комментарии. Раздел, написанный «для галочки», гарантированно порождает ветку на сорок сообщений.

Переписано:

Alternatives

A. Keep cron, add an advisory lock and a retry table.
   ~3 dev-days. Fixes duplicate sends. Does NOT fix the backlog: one node, one run
   per minute, 1.2k messages per run. Wins if we accept the backlog until Q4.

B. SQS + worker (proposed). ~8 dev-days, +45 USD/month at current volume.
   New failure mode: poison messages, mitigated by a DLQ and an alert (see Operations).

C. Kafka. ~20 dev-days. The data-platform cluster is single-region with a 99.5% SLO;
   password resets need 99.95%. A second consumer group needs a capacity change from
   @data-platform, ~3 weeks lead time. Wins if event sourcing lands (RFC-051), because
   then we need replay anyway.

D. Managed provider. ~2 dev-days, ~900 USD/month at current volume, moves e-mail
   addresses to a third party, which needs a security review we cannot finish before Q4.

E. Do nothing. Costs ~0. We keep the current 1-2 delayed-reset incidents per quarter
   and the manual re-send procedure in RB-07.

Теперь у каждого варианта есть цена в днях и деньгах, названо, что вариант чинит и чего не чинит, и указано условие, при котором он выигрывает. Заметьте формулировку у Kafka: это не отказ, а зависимость от другого решения — читатель, который её любит, получает не «нет», а «да, если». Вариант E делает честной саму развилку.

Пара 3: открытые вопросы

Как пишут обычно:

Open questions

- Any feedback is welcome.
- Are there any concerns?

На такой вопрос нельзя ответить неправильно, поэтому отвечают тем, что дёшево заметить: названиями полей, форматом дат, отступами в YAML. Это не злой умысел читателей — это прямое следствие того, что автор не сказал, какое именно знание ему нужно.

Переписано:

Open questions (answers block the start of work)

1. @billing-team: we plan to stop writing to the shared `notifications` table on
   2026-09-01. Does your reconciliation job still read rows older than 30 days?
   If yes, we need a read model instead, which adds ~4 dev-days.

2. @security: is a DLQ with 14-day retention acceptable for messages containing
   e-mail addresses, or do we redact at rest? This changes the worker, not the design.

3. Undecided by me: at-least-once with idempotency keys vs an outbox table.
   I lean to the outbox; the price is one more table and a nightly reconciler.
   This is the place where I most want to be argued out of my preference.

Три отличия: у вопросов есть адресаты, есть последствие ответа (плюс четыре дня, другой компонент), и автор честно называет место, где сам не уверен. Последний пункт делает для качества обсуждения больше, чем весь остальной документ: он показывает, что возражения здесь принимают, а не отражают.

Общий приём, работающий во всех трёх парах: заменяйте оценки фактами, а призывы — адресными запросами. Подробнее о механике предложений — в «Ясности», о порядке блоков — в «Структуре».

Как выносить: узкий круг раньше широкого

Главная процессная ошибка — сразу разослать черновик всем. Комментарии от тридцати человек приходят одновременно, половина из них — про вещи, которые вы бы поправили сами, а важное тонет. Работающий порядок — две волны.

Смысл первой волны — потратить чужие два часа вместо тридцати чужих получасов. Seed-рецензенты выбираются не по симпатии: это человек, который сильнее всех пострадает от вашего решения, и человек, который скорее всего будет против. Второй важнее первого — если он снимет возражение до рассылки, обсуждение пройдёт спокойно; если не снимет, вы узнаете об этом до того, как позвали тридцать человек.

Дальше — правила, без которых процесс разваливается:

• Дедлайн комментариев в шапке. «Комментарии до четверга 18:00, дальше принимаем вариант B» — единственный способ не превратить RFC в бесконечность. У Rust это Final Comment Period, у Apache — lazy consensus: молчание после явного срока считается согласием. Без срока и адресной рассылки правило не работает — через квартал вы услышите «нас не спросили», и формально это будет правдой.
• Явный решающий. Один человек, названный по имени. «Решает команда» означает «не решает никто»: документ висит месяцами, а потом решение принимается в коридоре.
• Встреча — не замена документу, а инструмент по спорным пунктам. Тридцать минут после того, как все прочитали, с повесткой из трёх нерешённых вопросов; приёмы ведения — в «Фасилитации». Если половина участников не читала, работает практика Amazon: первые пятнадцать минут все молча читают текст (описана в книге Colin Bryar, Bill Carr, «Working Backwards»).
• Асинхронность по умолчанию. Распределённая команда и часовые пояса — норма; документ тем и хорош, что позволяет возразить в своё утро.

Сроки: как выглядит здоровый цикл

Числа не догма, но пропорции устойчивы: на написание уходит меньше времени, чем на обсуждение, а обсуждение имеет конец. Для RFC-lite тот же цикл сжимается до трёх дней. Если ваш средний RFC живёт в статусе «на обсуждении» больше месяца, проблема почти никогда не в документе: нет решающего, нет дедлайна или решение на самом деле принимается в другом месте.

Жизненный цикл и статусы

Статус в шапке — дешёвая вещь, которая спасает будущего читателя от чтения устаревшего текста как актуального.

Три перехода, о которых обычно забывают. Rejected — нормальный исход, а не провал автора: организация, где отклонённых RFC ноль, либо не обсуждает, либо пишет документы задним числом. Stale с автозакрытием — механика, без которой репозиторий зарастает черновиками, и поиск начинает выдавать предложения, от которых все давно отказались. Superseded превращает набор документов в историю решений: новый RFC обязан назвать номер того, который он отменяет.

Работа с комментариями

Комментарии приходят вперемешку, и главная задача автора — рассортировать их до того, как отвечать. Полезны две оси: меняет ли комментарий решение и сколько стоит его учесть.

Практические правила:

• Отвечайте в документе, а не только в треде. Комментарий, учтённый правкой текста, снимает вопрос для следующих десяти читателей; ответ в ветке виден одному.
• Маркируйте типы возражений. Префиксы blocking:, important:, nit: — дешёвое соглашение, снимающее половину напряжения: читатель сам говорит, насколько всерьёз возражает.
• «Да, если» вместо «нет». «Мы это делать не будем» закрывает разговор; «сделаем, если задержка окажется выше 200 мс на нагрузочном тесте» превращает спор в проверяемое условие (приём описан у Squarespace как «The Power of Yes, if»).
• Не спорьте о вкусах в тексте документа. Именование, форматирование, порядок разделов — правьте или выносите в отдельный тред. Закон тривиальности Паркинсона («обсуждение велосипедного сарая») — не шутка про людей, а следствие того, что комментировать дешёвое проще; классическая формулировка — в письме Poul-Henning Kamp.
• Разделяйте несогласие и блокировку. IETF формализовал это как rough consensus: консенсус — не единогласие, а отсутствие неснятых существенных возражений (RFC 7282).
• Фиксируйте несогласие письменно. «@ivan остаётся при мнении, что outbox избыточен; решили начать с идемпотентных ключей и вернуться, если дублей будет больше 0,1%» — три строки, которые через год объяснят всё. Это и есть механика disagree and commit: человек не «проиграл», его позиция записана и у неё есть условие пересмотра.
• Отделяйте текст от себя. Возражение против документа — не оценка автора; как принимать правки без обороны — в «Ревью текста» и «Обратной связи».

Если обсуждение всё-таки ушло в конфликт интересов — например, две команды хотят владеть одним сервисом, — текст перестаёт быть инструментом; нужен разговор, а документ становится опорой для него: «Трудные разговоры».

Почему RFC устаревает раньше всех и что делать структурно

У RFC особая форма устаревания. ADR устаревать не должен: он описывает решение на дату и остаётся верным. README устаревает медленно. А RFC становится неправдой в момент принятия: дальше система живёт, а документ описывает намерение недельной давности. Опасность не в самом факте — опасно, когда читатель принимает RFC за описание того, как система работает сейчас. Типичный сценарий: новый инженер находит RFC-042 в поиске, реализует интеграцию по нему, и выясняется, что в реализации отказались от двух пунктов из трёх.

Призывы «поддерживать документацию в актуальном состоянии» здесь не работают вообще: обновлять RFC не нужно и вредно — это запись обсуждения, а не описание. Работают структурные меры.

Что именно ставят в процесс:

1. Неизменяемость после принятия. Принятый RFC не редактируют: правки только через новый RFC со ссылкой supersedes: RFC-042. Иначе история решений превращается в текущую версию без истории — а история и была ценностью.
2. Статус и дата в шапке, видимые сверху. Плюс автоматический баннер: «Принят 14 месяцев назад. Актуальное поведение — в docs/notifications.md». Один блок в шаблоне сайта документации снимает целый класс ошибок.
3. Выжимка в ADR — обязательный шаг закрытия. RFC на двенадцать страниц сжимается до полутора страниц контекста и решения и кладётся в репозиторий рядом с кодом. Это единственный артефакт, который переживёт автора; механика — в «ADR» и в «Архитектурных решениях».
4. Двусторонняя ссылка на реализацию. В RFC — ссылка на PR, в PR — ссылка на RFC. Линтер в CI помечает RFC в статусе Accepted, у которого через 90 дней нет ссылки на реализацию, и заводит тикет владельцу: либо реализовано, либо статус меняется на Withdrawn.
5. Автозакрытие черновиков. Draft без движения 60 дней уходит в Stale и закрывается; репозиторий не зарастает, поиск не выдаёт мусор.
6. Ничего проверяемого машиной внутри RFC. Схемы, списки эндпойнтов, значения по умолчанию не копируются в текст, а генерируются или даются ссылкой на файл в репозитории. Скопированный фрагмент схемы устареет к следующему спринту и будет врать дольше, чем весь остальной документ. Об этом же — «Документация API».
7. Индекс генерируется, а не ведётся руками. Таблица «номер, заголовок, статус, дата, реализация» собирается скриптом из шапок файлов. Ручной индекс расходится с реальностью за два месяца.
8. Архив не конкурирует с живой документацией в поиске. Тег archived, отдельный раздел, понижение веса в поиске. Читатель почти никогда не смотрит на дату — он смотрит на первый результат.

Общий принцип: устаревание лечится расположением документа, а не дисциплиной людей. Знание живёт там, где его дешевле обновить вместе с изменением, — рядом с кодом, в схеме, в тесте, в генераторе. Развёрнуто — в «Почему документация устаревает».

Когда RFC пишут ради процесса

Честно: в части организаций RFC — не инструмент обсуждения, а пропуск, без которого задачу не берут в спринт. Признаки, по которым это видно:

• Документ появляется после кода. Ветка готова, RFC пишется «чтобы согласовать».
• Ни одного отклонённого RFC за два года. Стопроцентное одобрение означает, что решение принимается не здесь.
• Диф между первой и принятой версией пустой. Обсуждение либо не было, либо прошло мимо документа.
• Комментарии про форму. Нумерация разделов, «нет раздела о рисках», «шаблон версии 3.2».
• Список согласующих вместо решающего. Семь подписей, каждая из которых ничего не решает, но каждая может задержать.
• Шаблон длиннее содержания. Четырнадцать обязательных разделов, из которых десять заполнены фразой «не применимо».

Быстрые проверки: попросите последнего рецензента назвать, что изменилось в проекте благодаря его комментарию; посмотрите, сколько RFC отклонено за год; сравните дату первого коммита кода с датой публикации документа.

Что с этим делать, по убыванию полезности и без саботажа (особенно если вы новый человек — см. «Первые 90 дней»):

• Разделить два документа. Обязательный процессный артефакт заполняется по шаблону и коротко; настоящее обсуждение выносится в RFC-lite на одну страницу до начала работы. Попытка совместить даёт текст, не работающий ни как то, ни как другое.
• Сохранить полезного зайца. Раз документ всё равно пишется, добавьте один живой раздел — альтернативы с ценой или открытые вопросы к смежникам. Часто именно он и начинает работать.
• Найти настоящего адресата. Иногда он есть, просто это не инженер: аудитор, служба безопасности, заказчик по контракту. Тогда документ не бессмыслен — у него другой читатель и другое решение, и писать его надо под них.
• Собрать данные и вынести вопрос. Не «процесс бессмысленный», а «за год 38 RFC, около 190 инженерных часов, отклонён ноль, средний срок согласования 24 дня; предлагаю сократить шаблон до пяти разделов и назначить одного решающего». Как готовить такой разговор — «Работа вверх».
• Начать с себя. Один RFC, написанный вовремя и с настоящими открытыми вопросами, меняет ожидания команды сильнее, чем предложение поменять процесс.

И зеркальный вопрос: не превратился ли ваш RFC в презентацию? Проверка — назовите пункт, который вы изменили из-за чужого комментария в последних трёх документах. Если такого нет, вы не обсуждаете.

Типичные ошибки

• Документ вместо спайка. Двенадцать страниц про то, что проверяется за два дня кодом.
• Рассылка всем сразу. Тридцать одновременных мнений вместо двух точных возражений.
• Нет дедлайна и решающего. Документ висит месяц, решение принимается в коридоре.
• Альтернативы для галочки. Три отказа с ярлыками порождают ровно те ветки, которые вы хотели предотвратить.
• Нет варианта «ничего не делать». Сразу видно, что решение уже принято.
• Раздел «влияние» без имён. Никто не понимает, что документ про него, и не приходит.
• Ответы только в тредах. Через месяц документ противоречит своим же комментариям.
• Скопированные схемы и списки полей. Устаревают первыми и портят доверие ко всему тексту.
• RFC как документация системы. Ссылка из README на RFC — почти всегда ошибка: ведите на актуальное описание, а на RFC — только из раздела истории.
• Обида на возражения. Возражение — то, ради чего документ написан; тишина чаще означает, что не читали, а не что согласны. А спор о названиях полей на четыре дня лечится не терпением, а разделом «не-цели» и префиксом nit:.

Практика

1. Разберите чужой RFC. Возьмите принятый документ вашей команды и выпишите: кто решающий, какой был дедлайн, какие альтернативы названы с ценой, какие открытые вопросы адресованы поимённо. Пустые графы — список того, что стоит поправить в шаблоне.
2. Сожмите до одностраничника. Возьмите свой последний дизайн-док и перепишите в одну страницу: запрос на решение, проблема с числами, предложение, три альтернативы с ценой, два открытых вопроса. Покажите обе версии коллеге и спросите, по какой ему легче возразить.
3. Найдите факт, который вас переубедит. Для текущего предложения напишите одну строку: «я откажусь от варианта B, если …». Не получается — вы пишете объявление; идите замерять.
4. Проведите seed-ревью намеренно. Перед следующей рассылкой отдайте черновик тому, кто скорее всего будет против. Сравните, сколько комментариев пришло потом.
5. Проверьте архив. Сколько RFC в статусе Accepted без ссылки на реализацию? Сколько черновиков старше трёх месяцев? Это ваш технический долг документации, и он измерим.

Источники

• RFC 1, «Host Software», Steve Crocker, 1969: https://www.rfc-editor.org/rfc/rfc1.html; его рассказ о происхождении названия: https://www.nytimes.com/2009/04/07/opinion/07crocker.html
• RFC 7282, «On Consensus and Humming in the IETF» — что такое rough consensus: https://www.rfc-editor.org/rfc/rfc7282
• PEP 1 — процесс и статусы предложений в Python: https://peps.python.org/pep-0001/
• Rust RFCs (Final Comment Period): https://github.com/rust-lang/rfcs; Kubernetes KEP: https://github.com/kubernetes/enhancements; Go proposal process: https://github.com/golang/proposal
• Oxide Computer, RFD 1: https://rfd.shared.oxide.computer/rfd/0001 и рассказ о процессе: https://oxide.computer/blog/rfd-1-requests-for-discussion
• Malte Ubl, «Design Docs at Google»: https://www.industrialempathy.com/posts/design-docs-at-google/
• Gergely Orosz, «Scaling Engineering Teams via RFCs»: https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/
• Apache Community, Lazy Consensus: https://community.apache.org/committers/lazyConsensus.html
• Squarespace Engineering, «The Power of Yes, if»: https://engineering.squarespace.com/blog/2019/the-power-of-yes-if
• Poul-Henning Kamp, письмо про велосипедный сарай: http://phk.freebsd.dk/sagas/bikeshed.html
• Colin Bryar, Bill Carr, «Working Backwards» — практика молчаливого чтения документа на встрече.

Мини-итог

• RFC существует ради возражений, а не ради описания. Продукт документа — согласие и зафиксированное несогласие с именами и условиями пересмотра.
• Окно узкое: слишком рано обсуждать нечего, слишком поздно — обсуждение становится согласованием задним числом. Признак окна — вы можете назвать факт, который вас переубедит.
• Запрос на решение, срок и имя решающего в первых пяти строках; без них документ живёт месяцами и умирает без решения.
• Альтернативы пишутся с ценой и условием победы, включая «ничего не делать»; открытые вопросы — адресно и с последствием ответа.
• Узкий круг раньше широкого: два точных возражения дороже тридцати мнений.
• Комментарии сортируются по паре «меняет решение — цена учёта»; вкусовое правится молча, блокирующее обсуждается лично, несогласие фиксируется письменно.
• RFC устаревает сразу после принятия — и это нормально. Структурные меры: неизменяемость, статус и баннер, выжимка в ADR рядом с кодом, двусторонняя ссылка на PR, автозакрытие черновиков, генерируемый индекс, никаких скопированных схем.
• Процессный RFC распознаётся по нулю отклонений, пустому дифу версий и комментариям о форме; лечится разделением слоёв, RFC-lite и разговором с числами.

Что дальше

Мы разобрали документ, который пишется до решения. Следующий жанр — документ, который пишется после события: как разобрать инцидент так, чтобы текст менял систему, а не искал виноватого, почему безупречность (blameless) — инженерное требование, а не вежливость, и как отличить список действий, который выполнят, от списка, который закроют формально.

Постмортем: документ, который меняет систему, а не ищет виноватого