Дизайн RFC-процесса для команды

Спроектируй RFC-процесс для команды {{team_size}}, хранение в {{stack}}.

Зачем RFC

RFC = Request For Comments. Async-документ для принятия architectural / product / process решений. Альтернатива impromptu Slack-обсуждениям и meeting-driven decisions.

Когда нужен RFC:

• Новый сервис / major architectural change
• Кросс-командная зависимость / API contract
• Изменение existing critical path
• Pricing / packaging изменение
• Process change для команды > 5 человек
• Любое решение которое будут вспоминать через год

Когда RFC overkill:

• Bug fix
• Feature внутри team scope без external impact
• Что уже решено и просто implementation detail

Формат RFC

Один template, обязательные секции:

# RFC NNN: [Title]

**Author(s):** @name
**Status:** Draft | In Review | Accepted | Rejected | Superseded
**Created:** YYYY-MM-DD
**Decision deadline:** YYYY-MM-DD
**Reviewers:** @name1, @name2, @name3
**Related:** RFC-XXX (если supersedes / расширяет)

## Summary
2-3 предложения. Что предлагается + ожидаемый impact.

## Problem
- Что не работает сейчас (с данными / quotes)
- Кого это касается
- Почему сейчас, а не через год
- Что произойдёт если не делать

## Goals
- Чего достигаем (measurable)
- Что НЕ цель (non-goals) — explicit, иначе scope-creep

## Alternatives considered
Минимум 3 варианта:
1. **Do nothing** — какой будет cost
2. **Alternative A** — описание, pro/con
3. **Alternative B** — описание, pro/con

Без альтернатив RFC = «единственное решение, апрувните» — это не RFC.

## Proposal
- Конкретное решение в деталях
- Архитектура / API / data model — диаграммы welcomed
- Phasing если multi-stage
- Migration plan если breaking

## Drawbacks
Honest: что плохого в proposal. Если нет drawbacks — недостаточно подумал.
- Cost / complexity
- Что блокирует / усложняет в будущем
- Edge cases которые не covered

## Unresolved questions
Что ещё не решено, что нужно обсудить в comments. **Это сильный сигнал зрелости RFC** — author признаёт что не всё знает.

## Decision (заполняется после ревью)
- Что решено
- Почему (rationale)
- Conditions / scope limitations

Reviewers — как выбрать

Не «весь engineering», иначе никто не ревьюит.

Total: 4-7 reviewers. Меньше — недо-validation. Больше — никто не отвечает (diffusion of responsibility).

В RFC явно указываются reviewers. Они получают notification. Они должны оставить comment (даже LGTM).

Timeline

Стандартный cycle:

Хорошее правило: если comment period затянулся > 3 недель — либо kill (никому не интересно), либо переформулируй (slishком broad).

Статусы

Rejected != bad. Rejected RFC = valuable record для будущих обсуждений «we tried that».

Хранение в {{stack}}

GitHub (recommended)

/rfcs/
  0001-postgres-to-cockroachdb.md
  0002-event-schema-v2.md
  0003-on-call-rotation.md
  README.md   ← index с статусами
  template.md

• RFC = pull request. Comments = PR comments.
• Status в frontmatter (parseable)
• Merge только after Accepted (или explicitly Rejected как record)
• Index auto-generated из frontmatter

Pros: version history, code-adjacent, review tools, search. Cons: non-engineers (PMs / designers) могут не любить GitHub UI.

Notion / Confluence

• Каждый RFC = page в RFC database
• Property: Status, Reviewers, Decision date
• Linked back в Notion calendar

Pros: non-eng-friendly, rich embedding (Figma / diagrams). Cons: хуже version history, comments менее structured.

Hybrid (RFC text в git, discussion в Notion / Slack)

Худший вариант. Discussion и решение должны быть рядом с документом, иначе теряются.

Numbering & naming

• Sequential: RFC-0001, RFC-0002, ...
• Filename: 0001-postgres-to-cockroachdb.md (number + kebab-case slug)
• Не пере-использовать номера если withdrawn

Что входит в Index README

# RFCs

| # | Title | Status | Author | Decision |
|---|---|---|---|---|
| 0001 | Postgres to CockroachDB | Accepted | @alice | 2026-01-15 |
| 0002 | Event schema v2 | In Review | @bob | — |
| 0003 | On-call rotation | Rejected | @carol | 2026-02-03 |

## How to write an RFC
- Use `template.md`
- Number = max existing + 1
- Open PR with single commit
- Tag reviewers in PR description

Process anti-patterns

• ❌ RFC после implementation («давайте сделаем post-hoc») — теряет смысл review
• ❌ Только Accept / Reject в comments без rationale — никто не учится
• ❌ Reviewer = «вся команда» — diffusion of responsibility
• ❌ Comment period > месяца — kill или re-scope
• ❌ Нет deadline — RFC болтается quarter-ами
• ❌ Decision maker не назначен — никто не принимает решение
• ❌ Хранить только в Slack threads — потеряешь через 6 мес
• ❌ Skipping Alternatives section — single-option «pls approve»

Adoption — как запустить

Прокатить RFC процесс — это process change. Шаги:

1. Pilot: 1-2 senior engineers пишут first RFCs на текущие проблемы — example-driven
2. Template + index: committed в repo, public
3. First все-team session: объяснить когда / зачем / как
4. Champion: один человек напоминает «может это RFC?» в Slack threads первые 2-3 месяца
5. Retrospective через квартал: RFC процесс работает? Что плохо? Iterate.

Не пытайся внедрить RFC «для всего» сразу — будет backlash. Начни с 1-2 типов решений (e.g. architectural changes), расширяй по мере adoption.

В конце

• RFC template для team
• Decision: где хранить + структура
• Reviewer guidelines (кто, сколько, что от них ждётся)
• Index с current open RFCs
• Adoption plan на 1-2 квартала
• Retrospective schedule