mirror of
https://github.com/nexu-io/open-design.git
synced 2026-05-31 19:04:39 +07:00
12ac2e988e
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>
191 lines
8.4 KiB
Markdown
191 lines
8.4 KiB
Markdown
# 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> · <b>简体中文</b> · <a href="MAINTAINERS.ja-JP.md">日本語</a></p>
|
||
|
||
本文档定义了 `nexu-io/open-design` 项目中**成为、担任、退出 Maintainer** 的规则。Core Team 个人名册由内部维护，本文档不公开列出——对外公开的是大家共同遵守的规则。
|
||
|
||
> **状态**：v1，2026-05-11 起草。配套文档 [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) 会把贡献者引到这里读完整规则。
|
||
|
||
---
|
||
|
||
## 角色定义
|
||
|
||
| 角色 | 权限 |
|
||
|---|---|
|
||
| **Contributor**（贡献者） | 任何提过至少 1 个 merged PR 的人，无特殊权限。 |
|
||
| **External Maintainer**（外部 Maintainer） | 按本文档规则晋升的社区贡献者。可 review、approve、关闭/重开 issue、自分配 issue。**不能点 Merge 按钮**——这一权限保留在 Core Team。 |
|
||
| **Core Team**（核心团队） | Open Design 内部团队。拥有完整仓库写权限，是治理决策的最终权威。名册由内部维护。 |
|
||
|
||
下文除非特别说明，**讨论的都是 External Maintainer**。
|
||
|
||
---
|
||
|
||
## Maintainer 比普通 Contributor 多什么权限
|
||
|
||
| 操作 | Contributor | Maintainer |
|
||
|---|:---:|:---:|
|
||
| Approve PR | ⚠️ 算评论，**不**算 merge 所需的 approve | ✓ 算 merge 所需的 approve |
|
||
| 关闭 / 重开 issue | 仅自己开的 issue | ✓ 任意 issue |
|
||
| 自分配未指派的 issue（优先 P0） | ✗ | ✓ |
|
||
|
||
### Merge 三条件
|
||
|
||
任何 PR——不论作者是谁——都需要**同时满足**：
|
||
|
||
1. 无代码冲突
|
||
2. CI 全绿
|
||
3. 至少 1 个 Maintainer 或 Core Team 成员 approve
|
||
|
||
Maintainer 的 approve 是绝大多数 PR 走的 merge 路径——这是 Maintainer 在项目日常中最直接的信任体现。
|
||
|
||
---
|
||
|
||
## 如何成为 Maintainer
|
||
|
||
入选有 **3 项标准**，**全部**满足才进入候选。
|
||
|
||
### 1. 贡献量
|
||
|
||
- **≥ 20 个 merged PR** 到 `nexu-io/open-design`
|
||
|
||
这是软门槛而非自动通行证——达到 20 PR 让你**进入考量**，不保证晋升。
|
||
|
||
### 2. 账号质量（防 bot / 防小号）
|
||
|
||
我们对候选人 GitHub 资料做 7 个维度检查。**7 项中至少 5 项达准入线，且零项触发一票否决。**
|
||
|
||
| # | 维度 | 准入线 | 一票否决线 |
|
||
|---|---|---|---|
|
||
| 1 | GitHub 账号注册时长 | ≥ 1 年 | < 90 天 |
|
||
| 2 | Public repos | ≥ 3 | 0 |
|
||
| 3 | Followers | ≥ 10 | < 3 |
|
||
| 4 | Followers / Following 比 | > 0.30 | < 0.05（典型刷号特征） |
|
||
| 5 | 资料完整度 | 自定义头像 **且** bio / company / blog / twitter 至少 1 项 | 默认头像 **且** bio/company/blog 全空 |
|
||
| 6 | 跨项目活跃 | 在 **本仓库以外** 至少 1 个公开仓库有 merged PR 或长期 issue/star 活动 | 仅在本仓库有贡献 |
|
||
| 7 | 账号状态 | 无 GitHub 平台限制（spam/banned/restored） | 任一限制 |
|
||
|
||
#### 早期项目例外条款（仓库满 6 个月后自动失效）
|
||
|
||
`nexu-io/open-design` 自首个 commit 起 6 个月内，**跨项目活跃**一票否决条款（#6）可由 Core Team 共识豁免，前提是：
|
||
|
||
- 维度 1 / 2 / 3 / 5 都明显高于准入线；**且**
|
||
- Core Team 经过实际 review 判断该候选人在本仓库的 PR 质量足够高
|
||
|
||
豁免决定需在 Core Team 内部记录中注明候选人姓名与日期。仓库满 6 个月后，本豁免条款不再可用。
|
||
|
||
### 3. 贡献质量（Core Team 综合评估）
|
||
|
||
定性评估，无固定公式。Core Team 关注：
|
||
|
||
- **代码质量**——merged PR 的正确性、scope 控制、对仓库 boundary 的尊重
|
||
- **Review 质量**——历史 review comment 是否有实质内容
|
||
- **社区参与**——Discussions / issue 分流 / Discord 互动
|
||
- **协作信号**——对 review feedback 的响应速度、修改意愿
|
||
|
||
通过前两项进入候选池，跨过第三项才被正式提名。
|
||
|
||
### 提名流程
|
||
|
||
1. 由某位 Core Team 成员在内部提出候选人
|
||
2. Core Team 内部达成共识
|
||
3. 一位 Core Team 成员私下联系候选人，确认意向
|
||
4. 进入 Onboarding
|
||
5. 公开 announce
|
||
|
||
**没有提名 PR、没有公开投票、没有固定任期**。这是有意做的选择——和 K8s/Apache 的 approver 投票模型相反——因为项目早期 Core Team 共识更快、决策质量相同。**当 External Maintainer 数量超过 5 人时，本节将被重新审视**。
|
||
|
||
---
|
||
|
||
## 责任与期望
|
||
|
||
**没有硬性指标。** 不设每周 PR review 数量、不设 issue 分流速率、不设响应 SLA。Maintainer 身份是对信任的认可，不是无薪工作。
|
||
|
||
我们在精神层面期望：
|
||
|
||
- 在你有上下文的 PR 上 approve；不熟悉的 abstain
|
||
- 尊重 Merge 三条件——你的 approve 是真信号，不是 rubber stamp
|
||
- 长期离线时在 `#maintainers` 提前打招呼
|
||
- `#maintainers` 中分享的未公开 roadmap 视为机密，不外传
|
||
|
||
如果 Core Team 观察到 bad-case 行为（草率 approve、恶意 close issue、泄漏未公开 roadmap 等），权限会按下节"强制退出"路径回收。
|
||
|
||
---
|
||
|
||
## Maintainer 专属权益
|
||
|
||
除上文所列仓库权限外，Maintainer 还会获得社区其他人没有的几样东西：
|
||
|
||
- **Discord `#maintainers` 频道**——与 Core Team 共享的私密工作空间。用于设计预览、RFC 草稿、未公开 roadmap 的内部协调
|
||
- **未公开 roadmap 的提前可见性**——你能在公开 announce 之前看到尚未发布的工作。Maintainer 同意在 Core Team 公开 announce 之前不外传内容
|
||
- **直通 Core Team 的沟通**——你在 `#maintainers` 的消息会得到比公开 Discussions 更快、更实质的回应，Core Team 在架构和 roadmap 决策上会主动征求 Maintainer 的意见
|
||
- **Maintainer 勋章**——你的 GitHub profile 与 MAINTAINERS 相关仓库表面上的公开信任标记（等 GitHub 自定义 badge 能力就绪后推出）
|
||
- **晋升时的公开认可**——Twitter / GitHub Discussions / Discord 三渠道同步 announce
|
||
|
||
---
|
||
|
||
## 退出（Step-down）
|
||
|
||
Maintainer 不是终身职位。三种退出路径：
|
||
|
||
### 主动退出（Graceful）
|
||
|
||
- Maintainer 私聊 Core Team 或在 `#maintainers` 公开说明
|
||
- 24 小时内回收权限
|
||
- 转入 **Emeritus** 状态
|
||
- 退出原因不要求公开
|
||
|
||
### 不活跃自动转（Inactive）
|
||
|
||
**触发条件**（任一即触发评估）：
|
||
|
||
- 连续 **90 天** 无任何活跃信号（merged PR / review comment / issue 处理 / Discussion 或 Discord 实质参与），**或**
|
||
- 连续 **60 天** 未响应任何 @mention（PR review request / issue assignment）
|
||
|
||
**流程**：
|
||
|
||
1. Core Team 在 `#maintainers` 私下 @ 提醒，给 **14 天回应窗口**
|
||
2. 14 天内仍无实质响应 → 转入 Emeritus，回收权限
|
||
3. 在 GitHub Discussions 公开发简短善意说明："感谢 @xxx 过去的贡献，已转入 Emeritus，欢迎随时回归"
|
||
4. 回归路径很简单——见下节 "Emeritus"
|
||
|
||
### 强制退出（For cause）
|
||
|
||
**触发场景**：
|
||
|
||
- 反复 bad-case 行为（草率 approve 不达标 PR、恶意关闭 issue、滥用权限等）
|
||
- 违反项目 [Code of Conduct][coc]
|
||
- 安全级别事故（账号被盗未及时报告 / 故意泄漏未公开 roadmap 等）
|
||
|
||
**流程**：
|
||
|
||
1. 任一 Core Team 成员可发起讨论
|
||
2. **至少 3 名 Core Team 成员**同意才执行（不需要全体共识）
|
||
3. 决定后 24 小时内：回收权限、移出 `#maintainers`、从任何 Maintainer 名册移除（**不**进入 Emeritus）
|
||
4. 当事人会被告知决定与理由，可申诉一次
|
||
|
||
原则是 **"倾向于保留 Maintainer"**——单次小过失不至于走强制路径，强制退出仅针对反复模式或严重单次事故。
|
||
|
||
[coc]: https://www.contributor-covenant.org/
|
||
|
||
---
|
||
|
||
## Emeritus（荣誉退役）
|
||
|
||
主动退出或不活跃转出的 Maintainer 进入 **Emeritus** 状态：
|
||
|
||
- 失去 write / approve / close 权限
|
||
- 在（内部）名册的 Emeritus 区块保留致敬
|
||
- 保留 Discord `#maintainers` 访问（read-only 或保留发言由 Maintainer 自选）
|
||
- 不再背任何责任
|
||
|
||
### 从 Emeritus 回归
|
||
|
||
最简回归路径：**最近 30 天有 ≥ 3 个 merged PR**，Core Team 即恢复权限，无需重新提名。
|
||
|
||
Emeritus 的意义是承认"生活会发生事"——休假、换工作、生孩子——双方都不需要任何 drama 或社交压力。
|
||
|
||
---
|
||
|
||
## 本文档的修订
|
||
|
||
本文档规则可由 Core Team 共识修订。**实质性变更**（准入门槛、退出阈值）会在 GitHub Discussions 提前 announce 后再对任何在审候选人生效；**编辑性澄清**可直接 land。
|