GNOME、大きな技術判断のためのRFCプロセスを起草

14日間のコメント期間、指名されたステークホルダー、そしてMerge Request。GNOMEは、いまチャットで決まっている判断を残す正式な手順（RFC、意見募集）を起草しました。

2026年9月5日3 分で読めます

他の言語で読む:原文（英語）Deutsch日本語Français Español Português

GNOMEのRFCプロセス草案を追加するGNOME GitLabのMerge Requestページ。コミット数と変更ファイル数が表示されている。

GNOMEは「どう決めるか」を決めようとしています。プロジェクトのRFC編集者であるSophie Herold氏が、大きな技術変更のための正式な手順を起草しました。Phoronixの報道によると、ステークホルダーが現在この案を議論しています。今は重要な判断がMatrixの部屋で決まり、そのまま失われることがあります。草案はそうした判断を、公開の場で、期限付きで、文書として残します。

この提案は2026年7月27日にGNOMEのDiscourseフォーラムに投稿されました。まだ提案の段階です。何も採用されていません。

手順はどう動くのか

ここでのRFCはRequest for Comments、つまり誰かが着手する前に公開の場で議論するための文書です。Rust、Python、Kubernetesも同様の仕組みを持っています。

GNOMEの草案は4つの部分から成ります。

手順	内容
提出	開発者が提案をMerge Requestとして出す
特定	編集者がその領域のステークホルダーを特定する
議論	Discourseで提案を議論する
決定	14日間の最終コメント期間の後、編集者とステークホルダーが判断する

各RFCは「議論中」「有効」「保留」の3つの状態のいずれかを持ちます。この設計では「ステークホルダー」という語が実際の役割を担います。ブロックする異議として数えられるのは、ステークホルダーの懸念だけです。誰でもコメントできますが、すべてのコメントが変更を止められるわけではありません。

草案はそれ自身を使って採用されます。反応が良ければ、この手順はRFC-0001として成立します。それを収めたMerge Requestには現在6つのコミットがあります。

なぜ今なのか

挙げられている問題は対立ではなく、記録です。重要な判断はIRCのログやMatrixの部屋に散らばったまま、非公式に下されています。こうした場所は検索が困難です。1年後には、誰が何に同意したのか、その理由は何だったのかを誰も言えなくなります。

Herold氏の提案は、文書として残すべきだった変更の例として、過去の3つの判断を挙げています。

GTKにおける新しいシンボリックアイコン形式
GdkPixbufから画像ライブラリGlycinへの移行
ドキュメント生成のgtk-docからgi-docgenへの移行

いずれも、それが決まった部屋の外にいる人たちの作業を変えました。アプリケーション開発者は追随を迫られ、多くの場合その理由を説明する文書はありませんでした。

GNOMEプラットフォームチームのEmmanuele Bassi氏は、設計について詳細な意見を寄せました。議論は敵対的ではなく、内容のあるものになっています。

読む価値のある反論

Benjamin Otte氏は適用範囲に異議を唱えました。結論が事実上決まっている技術的判断に、本当の方針決定と同じ手続きが必要なのかという問いです。

この反論はあらゆるRFCプロセスの核心です。文書化された手順は、議論が必要な判断を確実に拾います。同時に、必要のない判断にも負担をかけます。アイコン形式を変えるためにRFCを書かねばならないメンテナーは、変更そのものをやめてしまうかもしれません。GNOMEはまだこの点を解決しておらず、草案の現時点の答えは「どの変更が対象かは編集者が判断する」というものです。

オープンソースのガバナンスは今年、異例なほど注目されています。DebianはAI支援によるコントリビューションの扱いを正式な投票で決め、Nixpkgsのコアチームは10か月で解散し、燃え尽きとSteering Committeeとの摩擦を理由に挙げました。GNOMEは必要になる前に仕組みを作ろうとしています。