Перейти к содержимому
GitHubXDiscord

RFC-процесс

Для изменений, затрагивающих поверхность публичного API, семантику рантайма или что-либо, описанное в README или документации, открой RFC-issue до написания кода. Это позволяет избежать ситуации «неделя работы, отклонено на ревью», которая одинаково больно бьёт и по контрибьюторам, и по мейнтейнерам.

  • Новый публичный экспорт в любом пакете @triggery/*.
  • Breaking change в существующем публичном API.
  • Изменение семантики рантайма (порядок диспатча, поведение каскада, дефолты шедулера, формат инспектора).
  • Новый middleware-хук.
  • Переименование или перенос любой задокументированной опции.

RFC не нужен для:

  • Багфиксов, восстанавливающих задокументированное поведение.
  • Внутренних рефакторингов без изменений публичного API.
  • Улучшений документации, добавления тестов, бампов зависимостей.
  1. Открой RFC-issue через шаблон rfc.yml. Секции к заполнению:
    • Проблема — что не так сегодня, с конкретной пользовательской историей.
    • Предложение — изменение, максимально маленькое.
    • Альтернативы — хотя бы одна отклонённая альтернатива с причиной.
    • Миграция — как существующие пользователи дойдут до новой формы? Codemod предпочтителен там, где это механика.
  2. Получи одобрение ≥ 1 мейнтейнера на дизайн до написания кода. Одобрение даётся в треде issue, а не в PR.
  3. Открой PR, реализующий одобренный дизайн, и привяжи его к RFC-issue через Closes #N.
  4. Ревьюеры фокусируются на реализациидизайн уже принят. Существенные изменения дизайна на ревью означают повторное открытие RFC.

Не срочные RFC висят минимум 7 дней, чтобы сообщество успело высказаться. Security-чувствительные изменения могут двигаться быстрее на усмотрение лида проекта.

Если ни один мейнтейнер не возражает в течение 72 часов после того, как RFC достиг статуса «готов к мержу», изменение принимается. Возражения возобновляют дискуссию. Лид проекта разрешает тай-брейки, когда консенсус не достигается — см. GOVERNANCE.md.

После 1.0 breaking changes отгружаются только в мажорных версиях с минимум 30-дневным окном пре-релиза для тестирования сообществом. До 1.0 минорные версии могут включать breaking changes — codemod-скрипты поставляются там, где это механика.