vndangkhoa/open-design
1
0
Fork 0
mirror of https://github.com/nexu-io/open-design.git synced 2026-05-31 19:04:39 +07:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
open-design/MAINTAINERS.ja-JP.md
Joey-nexu 12ac2e988e
docs: add Maintainer rules (MAINTAINERS.md + CONTRIBUTING entry-point) (#1290) 
Adds a public set of rules for the External Maintainer role: who qualifies,
how nominations work, what permissions Maintainers gain, what's expected
of them, and how step-down works.

The Core Team's individual roster is intentionally not enumerated. What's
public is the rules everyone plays by.

- New file: MAINTAINERS.md (English authoritative version) + 5 locale variants
  matching the existing CONTRIBUTING.md i18n surface (de, fr, ja-JP, pt-BR,
  zh-CN). Non-EN/non-zh-CN variants are machine-translated drafts marked at
  the top — native-speaker review is welcome via follow-up PRs.
- CONTRIBUTING.md (and its 5 locale variants): adds a short
  Becoming a Maintainer section that points at MAINTAINERS.md, so the
  rules live in one place and translation drift is bounded.

Decisions not in this PR (intentional):
- No internal Core Team roster.
- No internal observability dashboards.
- No nomination PR / public voting flow (Core-Team-consensus-driven for now;
  to be revisited once External Maintainers exceed 5).

Co-authored-by: Joey Li <lijinwei@open-design.ai>
2026-05-11 20:19:55 +08:00

192 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!-- Machine-translated draft. Native-speaker review and corrections welcome via PR. -->
# Maintainers
<p align="center"><a href="MAINTAINERS.md">English</a> · <a href="MAINTAINERS.pt-BR.md">Português (Brasil)</a> · <a href="MAINTAINERS.de.md">Deutsch</a> · <a href="MAINTAINERS.fr.md">Français</a> · <a href="MAINTAINERS.zh-CN.md">简体中文</a> · <b>日本語</b></p>
このドキュメントは、`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 でアナウンスされます。編集上の明確化は直接反映できます。
Reference in a new issue View git blame Copy permalink