# Maintainers

English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語

このドキュメントは、`nexu-io/open-design` の Maintainer になるため、その役割を務めるため、そして退任するためのルールを定めるものです。Core Team の個別のメンバー一覧は内部で管理されており、ここには列挙していません。公に重要なのは、全員が従うルールそのものです。 > **ステータス**: v1、2026-05-11 にドラフト作成。[`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) のコンパニオン文書です。CONTRIBUTING.md は、コントリビューターを完全なルールのためにこちらへ案内しています。 --- ## 役割 | 役割 | 権限 | |---|---| | **Contributor** | 1 件以上の merged PR を持つすべての人。特別な権限はありません。 | | **External Maintainer** | 後述のルールにより昇格したコミュニティのコントリビューター。レビュー、approve、issue のクローズ/リオープン、issue の自己アサインが可能です。**merge button をクリックすることはできません** — それは Core Team に留まります。 | | **Core Team** | Open Design の内部チーム。リポジトリへのフルライト権限を持ち、ガバナンス上の決定における最終権限を有します。メンバー一覧は内部で管理されています。 | 特に断りのない限り、本ドキュメントの残りの部分は **External Maintainer** に関するものです。 --- ## Contributor にはできず Maintainer にできること | アクション | Contributor | Maintainer | |---|:---:|:---:| | PR を approve する | ⚠️ コメント扱いとなり、必要な承認には**カウントされません** | ✓ merge に必要な承認としてカウントされます | | issue のクローズ / リオープン | 自分が開いた issue のみ | ✓ 任意の issue | | オープンかつ未アサインの issue を自己アサイン（P0 を優先） | ✗ | ✓ | ### Merge の要件 PR は — 誰が作成したものであれ — 以下の **3 つすべて** が必要です： 1. コードコンフリクトがないこと。 2. CI が完全にグリーンであること。 3. Maintainer または Core Team メンバーから少なくとも 1 件の承認があること。 ほとんどの PR は Maintainer の承認を経て merge されます。これは、Maintainer の信頼がプロジェクトの日々の運営に最も直接的に表れる形です。 --- ## Maintainer になる方法 参入条件は **3 つ** あります。3 つすべてを満たす必要があります。 ### 1. 貢献量 - `nexu-io/open-design` への **20 件以上の merged PR**。 これはあくまでソフトな下限であり、自動的なチケットではありません。20 PR に到達することで検討対象に入りますが、役割が保証されるわけではありません。 ### 2. アカウントの品質（ソックパペット対策・ボット対策） 候補者の GitHub プロフィールを 7 つの観点で確認します。**7 項目中少なくとも 5 つの admission line をパスし、かつ veto line を 1 つもトリガーしないこと。** | # | 観点 | Admission line | Veto line | |---|---|---|---| | 1 | GitHub アカウントの年齢 | 1 年以上 | 90 日未満 | | 2 | パブリックリポジトリ数 | 3 以上 | 0 | | 3 | フォロワー数 | 10 以上 | 3 未満 | | 4 | フォロワー / フォロー比率 | 0.30 超 | 0.05 未満（典型的なフォローファームのパターン） | | 5 | プロフィールの完成度 | カスタムアバター **かつ** bio / company / blog / twitter のうち少なくとも 1 つ | デフォルトアバター **かつ** bio/company/blog がすべて空 | | 6 | クロスプロジェクト活動 | **別の** パブリックリポジトリで少なくとも 1 件の merged PR、または継続的な issue/star 活動 | merged PR が当リポジトリのみ | | 7 | アカウントの状態 | GitHub プラットフォームによる制限なし（spam/banned/restored） | 上記のいずれかに該当 | #### 初期プロジェクトの猶予条項（リポジトリが 6 ヶ月を迎えた時点で自動失効） `nexu-io/open-design` が初回コミットから 6 ヶ月未満である間は、以下の場合に **クロスプロジェクト活動** の veto（#6）を Core Team の合意により免除できます： - 観点 1、2、3、5 が admission line を明確に上回っていること。**かつ** - 当リポジトリにおける候補者の PR 品質が、Core Team の実地レビューにより高いと判断されること。 免除は、候補者の名前と日付とともに Core Team の内部記録に記載しなければなりません。リポジトリが 6 ヶ月に達した後は、この猶予条項は利用できなくなります。 ### 3. 貢献の品質（Core Team の判断） これは定性的なものであり、公式に基づくものではありません。Core Team は以下を見ます： - merged PR の **コード品質**（正確さ、スコープの規律、リポジトリ境界の尊重）。 - 他者の PR に残されたレビューコメントの **レビュー品質**。 - **コミュニティへの参加** — Discussions、issue トリアージ、Discord での関与。 - **協働のシグナル** — フィードバックへの応答性、修正への意欲。 最初の 2 つの基準を満たすことで候補者プールに入ります。この 3 つ目の閾値を超えることが、推薦されるための条件です。 ### 選考プロセス 1. Core Team メンバーが内部で候補者を提起します。 2. Core Team が合意に至ります。 3. Core Team メンバーが非公開で本人に連絡し、意思を確認します。 4. オンボーディング。 5. 公開アナウンス。 推薦 PR も公開投票も固定任期もありません。意図しているのは、**K8s/Apache 方式の approver 投票モデルの逆**です — プロジェクトの初期段階では、軽量な Core Team の合意の方が早く動き、同じ品質の結果を生み出します。External Maintainer のコホートが 5 名を超えて成長した時点で、このセクションは見直されます。 --- ## 責任と期待 **ハードなノルマはありません。** 週単位の PR レビュー件数も、最低限の issue トリアージ率も、応答時間の SLA もありません。Maintainership は信頼の認知であり、無償の仕事ではありません。 精神としてお願いしたいことは： - 文脈を理解している PR を approve すること。理解していないときは保留すること。 - merge 要件（§「Merge の要件」）を尊重すること — あなたの承認は実際のシグナルであり、形式的な押印ではありません。 - 長期間活動から離れる場合は `#maintainers` に知らせておくこと。 - `#maintainers` で共有される未公開のロードマップは機密として扱うこと。 Core Team が悪いケースの行動パターン（形式的な承認、悪意ある issue クローズ、未公開ロードマップの漏洩など）を観察した場合、§「Step-down — 理由ありの場合」に基づき権限が剥奪されます。 --- ## Maintainer 限定のアクセス 上記のリポジトリ権限に加えて、Maintainer は広いコミュニティが得られないものをいくつか受け取ります： - **Discord `#maintainers` チャンネル** — Core Team と共有されるプライベートな作業スペースです。デザインプレビュー、RFC ドラフト、未公開のロードマップに関する内部調整に使用されます。 - **機密ロードマップ** — まだアナウンスされていない作業への早期可視性。Maintainer は、Core Team メンバーが公にアナウンスするまで、その内容を機密として扱うことに同意します。 - **Core Team への直通ライン** — `#maintainers` のメッセージは、公開 Discussions よりも迅速かつ実質的な応答を得られます。Core Team は、アーキテクチャやロードマップの決定について、Maintainer の意見を真摯に求めます。 - **Maintainer バッジ** — GitHub プロフィールおよび MAINTAINERS 関連のリポジトリ表面に表示される、公的な信頼の印（GitHub のバッジ機能が整い次第展開）。 - **昇格時の公開的な顕彰** — 加入時に Twitter、GitHub Discussions、Discord でアナウンスされます。 --- ## Step-down Maintainership は終身任用ではありません。3 つの退出経路があります。 ### グレースフルな退任（自発的） - Maintainer が Core Team にメッセージを送るか、`#maintainers` に投稿します。 - 24 時間以内に権限が剥奪されます。 - Maintainer は **Emeritus** ステータスへ移行します。 - 公の理由は不要です。 ### 非アクティブによる移行 以下の **いずれか** に該当する場合、Maintainer は非アクティブ移行の対象として検討されます： - 90 日連続でアクティビティのシグナルがない（merged PR、レビューコメント、issue トリアージ、Discussion または Discord での実質的な参加）、**または** - 60 日連続で @-mention（PR レビューリクエスト、issue アサイン）に応答していない。 プロセス： 1. Core Team が `#maintainers` で非公開に Maintainer を @-mention し、**14 日間の応答期間** を与えます。 2. 14 日以内に実質的な応答がない場合、Maintainer は Emeritus へ移行し、権限が剥奪されます。 3. GitHub Discussions に、短くて温かい公開ノートを投稿します：「貢献ありがとうございました — Emeritus に移行されました。いつでも戻ってきてください。」 4. 戻るのは簡単です — 下記「Emeritus」を参照してください。 ### 理由ありの Step-down トリガーとなるもの： - 悪いケースの行動の繰り返し（例：基準を満たさない PR への形式的承認、悪意ある issue クローズ、権限の濫用）。 - プロジェクトの[行動規範][coc]違反。 - セキュリティ等級のインシデント（侵害されたアカウントの速やかな報告がない、未公開ロードマップの意図的な漏洩など）。 プロセス： 1. 任意の Core Team メンバーが議論を開始できます。 2. アクションを取る前に **少なくとも 3 名の Core Team メンバー** の同意が必要です（Core Team 全員の合意は必要ありません）。 3. 決定から 24 時間以内に：権限の剥奪、`#maintainers` からの除外、Maintainer ロスターからの削除（Emeritus へは移行**しません**）。 4. 影響を受けた本人には決定と理由が通知され、1 度だけ異議申し立てが可能です。 原則は **Maintainer を残す方向にバイアスをかける** ことです。1 度の小さな失敗は強制退任の理由にはなりません。理由ありの経路は、繰り返されるパターン、または重大な単発インシデントのみを対象とします。 [coc]: https://www.contributor-covenant.org/ --- ## Emeritus グレースフルに退任した、または非アクティブ経由で移行した Maintainer は **Emeritus** となります。Emeritus ステータスは： - write/approve/close 権限を削除します。 - （内部）ロスターの Emeritus セクションに本人の名前を残します。 - Discord `#maintainers` へのアクセスを維持します（読み取りまたは投稿 — Maintainer の選択）。 - 継続的な責任は伴いません。 ### Emeritus からの復帰 最もシンプルな復帰経路：直近 30 日以内に 3 件の merged PR を達成すれば、Core Team が権限を復元します。再推薦は不要です。 Emeritus の趣旨は、人生には色々あるということを認めることです — サバティカル、転職、子育てなど — どちら側にもドラマや社会的コストを生じさせることなく。 --- ## このドキュメントの変更について 本ドキュメントのルールは、Core Team の合意により改定可能です。実質的な変更（参入基準、退任しきい値）は、いかなる現役候補者にも適用される前に GitHub Discussions でアナウンスされます。編集上の明確化は直接反映できます。