open-design/MAINTAINERS.ja-JP.md

Maintainers

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

このドキュメントは、nexu-io/open-design の Maintainer になるため、その役割を務めるため、そして退任するためのルールを定めるものです。Core Team の個別のメンバー一覧は内部で管理されており、ここには列挙していません。公に重要なのは、全員が従うルールそのものです。

ステータス: v1、2026-05-11 にドラフト作成。CONTRIBUTING.md のコンパニオン文書です。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 クローズ、権限の濫用）。
• プロジェクトの行動規範違反。
• セキュリティ等級のインシデント（侵害されたアカウントの速やかな報告がない、未公開ロードマップの意図的な漏洩など）。

プロセス：

1. 任意の Core Team メンバーが議論を開始できます。
2. アクションを取る前に 少なくとも 3 名の Core Team メンバー の同意が必要です（Core Team 全員の合意は必要ありません）。
3. 決定から 24 時間以内に：権限の剥奪、#maintainers からの除外、Maintainer ロスターからの削除（Emeritus へは移行しません）。
4. 影響を受けた本人には決定と理由が通知され、1 度だけ異議申し立てが可能です。

原則は Maintainer を残す方向にバイアスをかける ことです。1 度の小さな失敗は強制退任の理由にはなりません。理由ありの経路は、繰り返されるパターン、または重大な単発インシデントのみを対象とします。

---

Emeritus

グレースフルに退任した、または非アクティブ経由で移行した Maintainer は Emeritus となります。Emeritus ステータスは：

• write/approve/close 権限を削除します。
• （内部）ロスターの Emeritus セクションに本人の名前を残します。
• Discord #maintainers へのアクセスを維持します（読み取りまたは投稿 — Maintainer の選択）。
• 継続的な責任は伴いません。

Emeritus からの復帰

最もシンプルな復帰経路：直近 30 日以内に 3 件の merged PR を達成すれば、Core Team が権限を復元します。再推薦は不要です。

Emeritus の趣旨は、人生には色々あるということを認めることです — サバティカル、転職、子育てなど — どちら側にもドラマや社会的コストを生じさせることなく。

---

このドキュメントの変更について

本ドキュメントのルールは、Core Team の合意により改定可能です。実質的な変更（参入基準、退任しきい値）は、いかなる現役候補者にも適用される前に GitHub Discussions でアナウンスされます。編集上の明確化は直接反映できます。