> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/engineering-practices/rfcs.md).

# RFCs

Что такое Requests For Comments, как и зачем их писать.

### Почему RFC <a href="#rfcs-pochemurfc" id="rfcs-pochemurfc"></a>

RFC дает возможность записать идеи и планы, которые могут быть реализованы в будущем. Через такой документ удобно вести обсуждения в распределенной команде и не терять контекст.

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

* Порядковый номер
* Статус
* Короткое название
* Направление
* Автор
* Дата создания

Процесс создания RFC и коммуникации должен быть легким и не требовать больших затрат времени и усилий.

RFC можно представить как асинхронный разговор. В отличие от чата, электронной почты или других каналов, использование RFC подразумевает, что:

* не требуется сразу отвечать
* у рецензентов есть время подумать и предложить изменения
* больше людей могут взаимодействовать одновременно не мешая друг другу
* RFC легко искать, и на них можно ссылаться
* RFC хранятся неограниченное время

### Когда использовать RFC <a href="#rfcs-kogdaispolzovatrfc" id="rfcs-kogdaispolzovatrfc"></a>

* Вы хотите сформулировать проблему и предложить решение
* Вам нужна вдумчивая обратная связь от членов вашей распределенной команды
* Вы хотите поделиться идеей, замечаниями или отзывом
* Вы хотите инициировать проект или предложить план реализации чего-нибудь, чтобы сформировать рабочую группу
* Необходимо подсветить и передать информацию о важном межфункциональном решении

### Когда не стоит использовать RFC <a href="#rfcs-kogdanestoitispolzovatrfc" id="rfcs-kogdanestoitispolzovatrfc"></a>

* Вы хотите обсудить личные или деликатные темы один на один с другим членом команды
* Вы хотите принять решение об изменении чего-либо, где вы являетесь решающим фактором – в подавляющем большинстве случаев создание RFC для объяснений будет излишним

### Формат документа <a href="#rfcs-formatdokumenta" id="rfcs-formatdokumenta"></a>

#### Порядковый номер <a href="#rfcs-poryadkovyinomer" id="rfcs-poryadkovyinomer"></a>

Каждый RFC имеет уникальный порядковый номер, который указывается в заголовке, например: `RFC 1 Ревью: Формат RFC` . Это облегчает быстрое обращение к конкретным RFC и упрощает поиск документа в Confluence. Порядковые номера также подсказывают в каком порядке создавались RFC.

#### Статус <a href="#rfcs-status" id="rfcs-status"></a>

Каждый RFC имеет статус в названии, например: `RFC 1 WIP: Рефакторинг логирования`&#x20;

Автор RFC отвечает за обновление статуса:

* **WIP** – автор еще работает над RFC, и он еще не готов к рассмотрению
* **Ревью проблемы** – есть четкая постановка проблемы или предложение, рецензенты проверяют гипотезу автора на корректность
* **Ревью решения** – проблема или предложение понятны, описано возможное решение, которое готово к рассмотрению
* **Принято** – если RFC предназначен для принятия решения, метка указывает на то, что решение принято
* **Реализовано** – в контексте принятого решения может быть сделана реализация, которую предлагает автор RFC
* **Закрыто** – RFC предназначался не для принятия решения и реализации и больше не является активным артефактом
* **Неактуально** – RFC предназначен для принятия решения, но нет планов по дальнейшим действиям

### Направление <a href="#rfcs-napravlenie" id="rfcs-napravlenie"></a>

Может быть, как общим, так и частным:

* Разработка
  * Бэкенд
  * Фронтенд
  * QA
  * Инфра
  * ...
* Продукт
  * Рассрочка
  * ...
* Процессы
  * Спринты
  * Требовавания
  * ...

По возможности данный тег необходимо унифицировать.