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>
8.4 KiB
Maintainers
English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
本文档定义了 nexu-io/open-design 项目中成为、担任、退出 Maintainer 的规则。Core Team 个人名册由内部维护，本文档不公开列出——对外公开的是大家共同遵守的规则。
状态：v1，2026-05-11 起草。配套文档
CONTRIBUTING.md会把贡献者引到这里读完整规则。
角色定义
| 角色 | 权限 |
|---|---|
| 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——不论作者是谁——都需要同时满足：
- 无代码冲突
- CI 全绿
- 至少 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 的响应速度、修改意愿
通过前两项进入候选池，跨过第三项才被正式提名。
提名流程
- 由某位 Core Team 成员在内部提出候选人
- Core Team 内部达成共识
- 一位 Core Team 成员私下联系候选人，确认意向
- 进入 Onboarding
- 公开 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）
流程：
- Core Team 在
#maintainers私下 @ 提醒，给 14 天回应窗口 - 14 天内仍无实质响应 → 转入 Emeritus，回收权限
- 在 GitHub Discussions 公开发简短善意说明："感谢 @xxx 过去的贡献，已转入 Emeritus，欢迎随时回归"
- 回归路径很简单——见下节 "Emeritus"
强制退出（For cause）
触发场景：
- 反复 bad-case 行为（草率 approve 不达标 PR、恶意关闭 issue、滥用权限等）
- 违反项目 Code of Conduct
- 安全级别事故（账号被盗未及时报告 / 故意泄漏未公开 roadmap 等）
流程：
- 任一 Core Team 成员可发起讨论
- 至少 3 名 Core Team 成员同意才执行（不需要全体共识）
- 决定后 24 小时内：回收权限、移出
#maintainers、从任何 Maintainer 名册移除（不进入 Emeritus） - 当事人会被告知决定与理由，可申诉一次
原则是 "倾向于保留 Maintainer"——单次小过失不至于走强制路径，强制退出仅针对反复模式或严重单次事故。
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。