← Все новости

Разработка ·

GNOME перешла на решения через RFC: финальный период комментариев и обязательные возраженияGNOME moves to RFC-based decisions with a final comment period and binding objections

В GNOME утвердили новый процесс принятия решений: крупные предложения теперь оформляются как RFC в отдельном репозитории, обсуждаются в Discourse и проходят 14-дневный финальный период комментариев. Цель — прозрачность и коллективная ответственность вместо личной.GNOME approved a new decision process: major proposals are filed as RFCs in a dedicated repository, discussed on Discourse and go through a 14-day final comment period. The goal is transparency and collective responsibility instead of personal.

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

Как это устроено:

  1. Автор кладёт в репозиторий GNOME/rfcs файл RFC-XXXX-название.md со структурированным предложением и ссылкой на обсуждение.
  2. Обсуждение идёт в Discourse, правки вносятся по ходу.
  3. Участники высказывают возражения с пометкой Concern. Если возражение поддержит редактор или один из заинтересованных участников, оно становится обязательным к рассмотрению.
  4. Автор разрешает возражения и меняет RFC.
  5. Объявляется 14-дневный финальный период комментариев (FCP), в котором принимаются только новые возражения. Если новое возражение принято, обсуждение перезапускается, а FCP сдвигается.
  6. После FCP и снятия всех возражений RFC принимается или отклоняется.

Зачем это нужно

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

Обратная сторона тоже очевидна: порог входа вырос. Раньше можно было открыть issue и надеяться, что кто-то из мейнтейнеров подхватит идею; теперь нужно оформить документ, завести обсуждение и пройти через формальные стадии. Для крупных изменений это оправданно, для мелких правок процесс не предназначен — их по-прежнему принимают обычными merge request’ами.

The RFC model will be used where a decision used to depend on who argued loudest: breaking deadlocks, approving architectural changes, major interface reworks, and global changes that affect how contributors work or touch code across several applications and subsystems.

How it works:

  1. The author adds RFC-XXXX-name.md to the GNOME/rfcs repository, with a structured proposal and a link to the discussion.
  2. Discussion happens on Discourse, with edits along the way.
  3. Participants raise objections marked Concern. If an editor or an interested participant supports an objection, it becomes mandatory to address.
  4. The author resolves the objections and updates the RFC.
  5. A 14-day final comment period (FCP) begins, during which only new objections are accepted. If a new objection is accepted, discussion restarts and the FCP moves.
  6. After the FCP and the resolution of all objections, the RFC is accepted or rejected.

Why bother

The point is not bureaucracy for its own sake but giving a contested decision a described path and protocol, with responsibility held collectively rather than personally. For outside contributors it also adds predictability: it is clear where a proposal goes, how long it will be discussed, and what counts as a blocking objection.

The downside is equally clear: the barrier to entry went up. Previously you could open an issue and hope a maintainer picked the idea up; now you write a document, start a discussion and walk through formal stages. For large changes that is justified; the process is not meant for small fixes, which still arrive as ordinary merge requests.

Источники

Похожие новости