RFC プロセス

RFC は、実装前にプロジェクトレベルの永続的な意思決定を記録します。このプロセスは、設計上のトレードオフを明らかにし、メンテナーやコントリビューターが早い段階で異議を唱える機会を設け、意思決定に至った_理由_を検索可能な記録として残すために存在します。

ほとんどの作業にRFCは必要ありません。RFCを起動する条件は意図的に絞られており、プロジェクトレベルの判断が本当に必要な提案が、通常の機能に埋もれて順番待ちにならないようにしています。

RFCの対象範囲と承認ルールはFND-003で定義されています。現行のプロトコルは#9496で範囲が絞り込まれ、#10288で保留中の投票について明確化され、#10549で簡素化されました。

RFCを提出すべきか、それともPRだけで十分か

実装前に永続的なプロジェクトレベルの決定が必要な提案、つまり少なくとも次のいずれかに該当する場合は、RFCを提出します。

新たなセキュリティレイヤー、またはプロジェクトのセキュリティモデルへの重大な変更;
ガバナンス、コントリビューションプロセス、またはプロジェクトの権限に関する変更;
既存の境界をまたいで所有権または契約を変更する、横断的なアーキテクチャのリファクタリング。または
新しいサブシステム、またはプロジェクト全体に関わる別の機能境界。

作業に以下が含まれるというだけの理由で、RFC を提出しないでください：

通常の機能追加;
スキーマまたはデータの移行;
設定項目またはデフォルト値の変更、または
範囲を限定した実装のリファクタリング。

これらは issue と PR を通します。新しいチャネル、新しいプロバイダー、新しいツール、バグ修正は、diff がどれほど大きくても、すべて通常の作業です。実質的な影響が上記4つのトリガーのいずれかにも該当する場合に限り、RFC が必要になります。

この判定が基準とするのは、課題のタイトル、作成者、ドラフトが AI の支援を受けたかどうか、あるいはマイグレーション、機能、デフォルトの変更が単に含まれているかどうかではなく、プロジェクトに対する実質的な影響です。判断に迷う場合は、通常の issue を作成し、どのトリガーに該当する可能性があると考えているのか、その理由を記載してください。メンテナーが RFC に格上げできます。そのほうが、RFC を停滞させるよりもはるかにコストがかかりません。

セキュリティ脆弱性は SECURITY.md に従って非公開で報告し、公開 RFC として報告することは決してありません。

メンテナーは、提出された RFC がトリガー条件を満たさない場合、それを通常の issue、機能リクエスト、または実装フォローアップとしてラベルを付け替えたり、クローズしたりすることがあります。その扱いは、基盤となる作業が引き続き有効かどうか、またどこで継続されるかを示すものであり、内容そのものに対する却下ではなく、振り分けの判断です。

RFCの提出

RFCは type:rfc タグ付きのGitHub Issueです。タイトル形式:

RFC: <short description of the proposal>

本文の構成: 提案の規模に合わせて調整してください:

問題: どのようなユーザーの不便やシステムの欠陥がこれを引き起こしているのか?
提案: 何をしようと提案していますか?
設計: 詳細、コードスケッチ、スキーマの形状、マイグレーション計画
検討した代替案: 他に何を評価し、なぜ採用しなかったのか？
非目標: この提案が明示的に解決しようとしていないこと
リスクと軽減策: 何が問題になり得るか、そしてロールバックの手順
ロールアウト: フィーチャーフラグ管理されているか？スキーマがバージョン管理されているか？破壊的変更のウィンドウは？

Filed RFCs go through snapshot preparation and discussion, but there is no mandatory minimum discussion timer. Anyone can comment. Maintainers weigh in. The author iterates on the body in response.

Wait—I need to correct myself. The system instructions state I should return only the translated string, so here is the translation:

提出済みのRFCはスナップショットの準備と議論のプロセスを経ますが、必須の最低議論期間はありません。誰でもコメントできます。メンテナーも意見を述べます。著者はそれに応じて本文を繰り返し修正します。

Core の投票は、提案に目に見える安定したスナップショットがあり、投票を開始する人が RFC のトリガーを特定し、Core コントリビューターがそのスナップショットを決定に付すことに同意している場合に開始できます。投票前の本文の編集は、自動的な待機期間を再開させません。投票開始後の本文の編集は、現在の投票を重大な置き換えとして停止するか、次の改訂まで投票対象のスナップショットの外に置かれます。

承認

A投票サイクルは、通常、不変の提案スナップショットに対して72時間開かれたままになります。このスナップショットは、不変のアーティファクトまたはコミット、あるいは記録された Issue 本文のダイジェストと簡潔な決定概要によって識別されます。投票開始コメントには、スナップショット、割り当てられた有権者、閾値とその適用理由、定足数には2件の明示的な投票が必要であること、そして正確なUTCの締切時刻を記録します。このプロトコル外の独自の終了条件を追加することはできません。

投票資格者。 アクティブな Core コントリビューターとは、過去30日以内に正式に開始された RFC 投票で明示的な投票を行った、現在の Core Team メンバーを指します。その集合に含まれない現在の Core Team メンバーも引き続き投票できます。そうすることで、その投票の投票資格者に加わり、後続の投票に向けて再びアクティブになります。

投票の種類は APPROVE、REVISE、REJECT です。APPROVE は、スナップショットを記載どおりに承認します。必要に応じて実装上の境界を付記できます。REVISE は、影響を受ける契約または本文の用語、必要な本文の変更または決定事項、そしてその曖昧さが承認を妨げる理由を明示した場合に、現在のスナップショットを停止します。REJECT は阻止的な異議であり、具体的な理由が必要です。投票期間が開いている間は、記録された締切前の最新の APPROVE または REJECT が、それ以前の投票に優先します。有効な REVISE は、そのスナップショットに対して最終的なものです。

しきい値。 デフォルトでは最終的なアクティブ投票者の3分の2とし、投票者数の整数に切り上げます。定足数には少なくとも2票の明示的な投票が必要であり、沈黙は定足数に算入されません。定足数に達すると、通常の投票では投票者の沈黙を APPROVE とみなします。全会一致は、コストや不可逆性のために特別多数では不十分となる決定（ライセンスや法的所有権の変更など）に限られます。全会一致には割り当てられたすべての投票者による明示的な APPROVE が必要であり、沈黙によって成立することはありません。

結果（次の順序で適用）:

Returned to revision（差し戻し）: 期限前に有効な対象の REVISE が出されると、現在のスナップショットは停止されます。差し戻し記録には、ブロックしている本文の変更または必要な判断が明記されます。
保留: 明示的な投票が2件未満である場合、または定足数は満たされているものの、有効な REVISE または REJECT がなく、該当する閾値または必要な明示的承認がまだ満たされていない場合、投票は締め切ることができません。提案は、同じ不変のスナップショットに対して、さらに72時間のサイクルに入ることがあります。継続または再開の記録には、変更のないスナップショット、持ち越される投票、これまでの有権者、閾値、不足している条件、および正確なUTCの期限が記載されます。既存の明示的な投票は、更新されたサイクルにおいて定足数と結果の両方に算入され、撤回されるか後の投票に置き換えられるまで持ち越されます。提案の重要な変更は、新しいスナップショットを作成します。
却下: 定足数を満たし、最終投票のいずれかが REJECT。ブロッキングとなった異議を記録し、根本的な問題が継続している issue があればリンクして、Issue をクローズします。これは提案を却下するものであり、必ずしも問題そのものを却下するものではありません。
承認: 定足数に達し、有効なREVISEまたはREJECTがなく、該当する閾値を満たしていること。デフォルトでは、明示的または無応答により3分の2以上が承認していることを意味します。例外的な全会一致の投票では、割り当てられたすべての投票者からの明示的なAPPROVEが必要です。Issueにはstatus:acceptedが付与され、クローズ記録または実装への引き継ぎには、提起された場合に限り、非ブロッキングの実装上の境界が記録されます。実装PRは、この引き継ぎが可視になった時点で進めることができます。
差し戻し: 提案本文に実質的な変更が加えられた場合、または決定前に作成者が改訂を求めた場合。差し戻し記録には、次に安定する提案の対象、または必要な改訂内容を記載する。
取り下げ: 提案者が撤回します。再提案を妨げずにクローズされます。

REVISE であっても、具体的な反対事由を示していないものは、是正されるまで投票を停止させず、定足数にも数えられません。投票の発起人は説明を求めることはできますが、形式上有効な REVISE を単独で無効とすることはできません。有効性に争いがある場合は、他の Core contributor 1 名が当該投票を無効と認めれば無効となり、そうでなければ投票は有効のままとなります。

Silence-as-approval（沈黙を承認とみなす扱い）は、投票期限に達し、かつ有効な REVISE または REJECT がない状態で投票がまだ開いている場合にのみ評価されます。沈黙が停止されたスナップショットを上書きすることはありません。

投票は、最終的なアクティブ投票者全員が明示的に承認し、非アクティブな Core コントリビューターから全期間を求める要請がない場合に限り、早期に終了できます。終了記録には、早期に終了した理由を記載する必要があります。

現行のプロトコルは、その改訂を批准するドキュメントPRがマージされた後に開始されたRFC投票に適用されます。ただし、Coreが特定のIssueで以前からの適用を明示的に記録した場合はこの限りではありません。以前に承認されたRFCを自動的に無効とするものではなく、過去のプロセスの監査と修正作業は別途追跡されます。

投票記録

このガイドの散文要件を、投票の開始・継続・終了コメントの正式な形式としてください。別途必要な投票記録テンプレートはありません。RFC issueフォームが収集するのは最初の提案であり、投票記録ではありません。FND-003が投票の有効性、締切、結果の優先順位を規定します。

開始レコードには、上記の承認フィールドと並べて、RFCのトリガーとスナップショットの準備が整った理由を含めます。スナップショットに変更がない継続レコードには、取り下げまたは差し替えられていない引き継ぎ投票を列挙し、新しい正確なUTC期限を設定します。投票を無期限に保留のままにすることはありません。クローズまたは差し戻しのレコードには、スナップショット、有効な投票、結果と理由、そして必要な改訂、実装の境界、または継続を明記します。有効かつ資格のあるREVISEは、クローズ時に集計して見過ごされる懸念事項となるのではなく、そのスナップショットを停止させます。

採用されたRFCの実装

実装のPRには以下が含まれているべきです：

実装を開始する前に、RFC issue に最終的に承認された形と恒久的な処理結果が記録されていることを確認してください
RFCのissue番号を参照してください（Implements #5574 phase 1）
承認された設計の範囲内で対応し、実装中に詳細が変更された場合は、RFC 本文を更新するか、フォローアップの明確化のための issue を作成してください
RFCで段階的なロールアウトが求められている場合は、フィーチャーフラグの背後に配備してください。
破壊的変更の影響を受けるユーザー向けの移行パスを含める

大きなRFCは、複数のリリースにわたって複数のPRで提供されることがよくあります。RFCの追跡コメントは、フェーズが実装されるたびに更新されます。

現在公開されているRFC

Open RFCは、ZeroClawにおける「次に来るもの」の最も良い一次情報源です。閲覧:

sh

gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open

そのクエリが正式な情報源です。このページでは、意図的にそのスナップショットを反映していません。手作業で管理するリストは、誰も気づかないうちにすぐ古くなってしまうためです。

承認された基礎的なRFC

これらは他のすべての要素に影響を与えます。横断的な変更を提案する前に、これらをお読みください：

#5574: マイクロカーネルへの移行: クレート分割、フィーチャーフラグの分類、v1.0 への道筋
#5576: ドキュメント標準とナレッジアーキテクチャ
#5577: プロジェクトガバナンス: コアチーム、および本ドキュメントの権限。このRFCの適用範囲と投票のしきい値は、#9496 (FND-003 Rev. 15) により置き換えられています
#5579: エンジニアリング基盤: CIパイプライン、リリース自動化
#5615: コントリビューション文化: 人間とAIの共同作成に関する規範
#5653: 妥協なし: エラーハンドリング、デッドコードポリシー、リリース準備基準

AIが作成したRFC

RFCの著者としてAIアシスタント（人間のスポンサー付き）が関与することは、RFC #5615により明示的に許可されています。もしRFCがAIの助けを借りて作成された場合:

本文に明記する（“drafted with Claude, reviewed by @maintainer”）
スポンサーの人間は、正確性とレビューへの対応を担当します。
現在の Core Team メンバーのみが拘束力のある票を投じます。AI が下書きした RFC のスポンサーになっても投票権限は生じず、提案が AI の支援を受けて作成されたというだけで、その提案が RFC トリガーの条件を満たすかどうかが変わることもありません。

これまでのところ、この方法はうまく機能しています。AIによるドラフトを正規のものとして扱いつつも、最終的な責任はスポンサーにあることを忘れないでください。

ZeroClaw Docs