tldr-pages 社区角色体系解析：从贡献者到维护者的晋升路径与实操流程
tldr-pages 社区角色体系解析：从贡献者到维护者的晋升路径与实操流程
tldr-pages（Collaborative cheatsheets for console commands）是一个由社区共建的命令行速查手册仓库，其核心内容存放在本仓库的 pages/ 目录下，包含数十种语言的上万条命令速查页。本文以仓库根目录的 COMMUNITY-ROLES.md 为骨架，系统梳理该项目"从新贡献者到仓库协作者、再到组织成员与组织所有者"的完整角色流转机制，并结合 GOVERNANCE.md、MAINTAINERS.md、contributing-guides/maintainers-guide.md 与 .github/CODEOWNERS 等仓库文档，给出可量化、可执行的晋升标准与面向组织所有者的落地操作流程。读完本文，你将能准确判断自己处于哪一角色阶段、距离下一级还差哪些客观指标，也能掌握作为组织所有者发起角色变更 Issue、更新 MAINTAINERS 列表与维护 CODEOWNERS 的完整操作路径。
角色体系的设计理念：以"认可实际工作"替代"指派职务"
tldr-pages 的角色体系有一个非常明确的设计前提：项目应能动态、灵活地适应贡献者投入度与兴趣的自然波动，从而提升长期韧性、降低维护者倦怠风险，并避免出现 单一故障点（即某个人的离开导致项目瘫痪）。
为此，COMMUNITY-ROLES.md 明确写道：这些准则的取向是认可人们已经在做的工作，而不是向人们指派角色与任务。也就是说，任何社区成员都可以按照自己喜欢的方式参与贡献，项目方则尽力扫除这些贡献路上的障碍；当贡献者的实际工作积累到客观阈值时，角色自然随之升级。
这套流程强调三个特性：
- 客观性：角色转换所依据的指标是"客观、易于核查、有明确文字描述"的（例如合并 PR 的数量、审查 PR 的次数），而不是靠主观印象；
- 透明性与可预期性：任何人都可以阅读文档、预判自己何时达标；
- 非硬性规则：文档同时强调这些指标"并非一成不变的死规则"，例外情况可以通过开放的社区讨论来裁定。
这一"去中心化、去等级化"的取向，也与 GOVERNANCE.md 中"项目力求开放、欢迎、非等级化的治理结构"以及"社区角色应反映实际活动"的原则相互呼应——角色不是自上而下授予的权力头衔，而是对成员实际组织工作的动态映射。
角色总览：四级阶梯与对应权限
从仓库文档（MAINTAINERS.md 与 COMMUNITY-ROLES.md）可以归纳出 tldr-pages 社区的四级角色阶梯：
| 角色层级 | 覆盖范围 | 核心权限 |
|---|---|---|
| 普通贡献者（Contributor） | 无特殊权限 | 提交 Issue、提交 Pull Request |
| 仓库协作者（Repository Collaborator） | 单个仓库（如 tldr-pages/tldr） | 直接推送提交、合并 PR、打标签、关闭 Issue 等 |
| 组织成员（Organization Member） | tldr-pages 组织下所有仓库 | 向组织全部仓库推送提交、合并 PR、打标签、关闭 Issue，以及若干额外的维护能力 |
| 组织所有者（Organization Owner） | tldr-pages 组织 | 增删组织成员、管理全部仓库、配置集成、执行角色变更等管理操作 |
其中"仓库协作者→组织成员"之间还叠加了一层维护工作（maintenance work）的判定维度：维护工作指的是"为其他人的贡献提供便利"，在本项目中通常体现为审查或合并 PR，这正是从"会写代码的人"升级为"能治理社区的人"的关键分水岭。
何时晋升：三条量化标准与一条退出机制
COMMUNITY-ROLES.md 的"When to change roles"章节给出了四个触发条件，全部基于可核查的公开数据：
标准一：从贡献者到仓库协作者
当一个贡献者在 tldr-pages 组织旗下的某个仓库中，累计有至少 5 个非平凡的 Pull Request 被合并（非平凡意为真实有效的内容变更，而非琐碎的 typo 修复）时，就应被邀请成为该仓库的协作者（collaborator）。
核查方法：访问 https://github.com/tldr-pages/tldr/commits?author=<username>，即可查看某位贡献者的合并记录。
成为协作者意味着：可以直接向该仓库推送提交，可以合并 PR、给 Issue 打标签、关闭 Issue，以及执行其他维护任务。
标准二：从仓库协作者到组织成员
仓库协作者如果定期执行维护任务，则应被提升为组织成员。具体量化条件为：
- 至少合并 10 个 PR；
- 对 PR 提交至少 5 次非平凡的审查（review）。
需要特别注意的是，这两项指标可以有重叠——也就是说，你自己合并的 10 个 PR 同时也可以计入那 5 次审查（reviewed-by 查询会覆盖你审查过的 PR，包括你自己合并的那些）。
核查方法：访问 https://github.com/tldr-pages/tldr/pulls?q=reviewed-by:<username>。
组织成员意味着：可以向组织旗下所有仓库推送提交、合并 PR、打标签、关闭 Issue 等；此外，根据 MAINTAINERS.md 中的说明，组织成员还拥有若干额外的维护能力。
[!IMPORTANT] 组织所有成员必须将自己在组织中的成员身份设为公开（public）。
标准三：从组织成员到组织所有者
组织成员如果保持活跃至少 6 个月，就应被邀请成为组织所有者（owner）。这里的"活跃"以 MAINTAINERS.md 中记录的成员名单与任期为准。
组织所有者意味着：可以向组织添加成员、管理组织旗下所有仓库、配置集成等，并承担执行社区角色变更的职责（见下文"谁可以变更角色"）。
标准四：角色的临时性与退出机制
文档特别强调：这些角色是临时的，而且这是合理的。人的兴趣与可用时间会自然变化，因此项目应当定期更新各角色的人员名单，使其准确反映"当下真正在管理项目"的活跃团队，同时避免给重心已经转移的人传递过度的义务感。
具体触发条件：如果某组织成员超过 6 个月不活跃，其成员身份就应被同步停用。但需要注意两个重要的缓冲细节：
- 该成员仍保留在其过往活跃过仓库中的协作者身份（即降级为协作者，而非彻底除名）；
- 这"仅仅是对其实际参与程度的反映，绝不是降级或惩罚"；一旦该成员重新回到活跃参与状态，就应将其重新加回组织，以如实反映事实。
这一机制在 MAINTAINERS.md 中也有大量实例佐证：许多成员的历史记录呈现"首次加入—暂停—再次加入"的形态（例如多位维护者都经历过 2018 年组织重组时的身份变更），说明这套"可进可出"的动态机制在实践中是常态而非例外。
如何变更角色：面向组织所有者的四套操作流程
COMMUNITY-ROLES.md 的"How to change roles"章节面向组织所有者（即有能力执行这些变更的人）给出了完整流程。整体方法论是：先发现——审查该贡献者近期的贡献是否符合上一节的量化标准；再提议——打开一个新 Issue，以给定模板为基础提出角色变更；最后落地——在 GitHub 界面执行权限操作，并通过 PR 更新 MAINTAINERS.md 名单。
下面四套流程，每一步都包含可直接复用的 Issue 模板与回复模板。
流程一：添加新的仓库协作者
第 1 步：打开一个提议 Issue，使用以下消息模板（按需编辑）：
Hi, @username! You seem to be enjoying contributing to the tldr-pages project.
You now have had five distinct pull requests merged!
That qualifies you to become a collaborator in this repository, as explained in our <a href="https://link.gitcode.com/i/f18b50d1f8e797780ddbb11e613b64a6" target="_blank">community roles documentation</a>.
As a collaborator, you will have commit access to the repository.
That means you can merge pull requests, label and close issues, and perform various other maintenance tasks that are needed here and there.
Of course, all of this is voluntary — you're welcome to contribute to the project in whatever ways suit your liking.
If you do decide to start performing maintenance tasks, though, we only ask you to get familiar with the <a href="https://link.gitcode.com/i/36e1bfdb1725c05d967e3b82b67ee628" target="_blank">maintainer's guide</a>.
So, what do you say? Can we add you as a collaborator?
Either way, thanks for all your work so far!
> [!NOTE]
> It is required to have a secure two-factor authentication (2FA) method (Authenticator app/Security Keys/GitHub mobile) enabled for your
> GitHub account to be added as a collaborator to the tldr-pages/tldr repository.
第 2 步：等待对方确认并接受邀请后，前往仓库的 Settings → Collaborators 页面（即 https://github.com/tldr-pages/tldr/settings/collaboration），以**写权限（write permissions）**将其添加为仓库协作者。
第 3 步：建议对方开一个 PR，把自己的名字添加到 MAINTAINERS.md 的"Repository collaborators"一节，并务必在 PR 描述中包含 Closes #<issue number>，这样该 Issue 会在 PR 合并后自动关闭。
可复用的回复评论模板：
Welcome to tldr! I've sent you an invitation to become a collaborator in this repository.
Feel free to close this issue with a pull request, updating the <a href="https://link.gitcode.com/i/0e7a32c3dfe1ce20c1cbe3e7f9faad3c" target="_blank">MAINTAINERS.md</a> file's active collaborator section with a new entry.
Also add yourself to the <a href="https://link.gitcode.com/i/37875336800ce6f7d003d9d798c82614" target="_blank">CODEOWNERS</a> file if you wish to take responsibility for reviewing PRs for a language's translations or a specific directory.
We also have a Matrix chat room, which we recommend as a way to stay in touch with community discussions and other maintainers.
流程二：添加新的组织成员
第 1 步：打开提议 Issue，使用以下模板：
Hi, @username! After joining as a collaborator in the repository, you have been regularly performing maintenance tasks.
Thank you for that!
According to our <a href="https://link.gitcode.com/i/f18b50d1f8e797780ddbb11e613b64a6" target="_blank">community roles documentation</a>, you've now met the thresholds to be effectively considered an active maintainer of the project.
To publicly acknowledge that fact, we'd like to add you to the tldr-pages organization.
If you accept the invitation, we ask you to make your membership public and (in case you don't already) start hanging out in our Matrix chat room.
Additionally, consider subscribing to the notifications from the various repositories under the tldr-pages organization.
As one of the public faces of the tldr-pages project, it's also especially important that you follow and encourage the <a href="https://link.gitcode.com/i/923e5aaccca2380a16d6faf989ff1085" target="_blank">project governance principles</a>.
How does that sound? Are you up for it?
第 2 步：对方接受邀请后，前往 https://github.com/orgs/tldr-pages/people 将其添加为组织成员。
第 3 步：建议对方开 PR，把自己的名字移动到 MAINTAINERS.md 的"Organization members"一节（同样包含 Closes #<issue number>）。注意回复模板中的一个细节：需要把原有"Repository collaborators"中的条目移到协作者列表底部，以保持历史记录整洁。
可复用的回复评论模板：
Welcome to the team! I've sent you an invitation to become a member of the organization. Once you accept it, don't forget to set your membership to "Public" visibility.
Feel free to close this issue with a pull request, updating the <a href="https://link.gitcode.com/i/f6529c40b328c2eea805139f78db7ead" target="_blank">MAINTAINERS.md</a> file's active organization members section with a new entry.
Make sure to update your existing <a href="https://link.gitcode.com/i/617ada72fb676532783d2e4c98916318" target="_blank">repository collaborator</a> entry in <a href="https://link.gitcode.com/i/b718d59ce680c88daf5efc1fe7f5e047" target="_blank">MAINTAINERS.md</a> file and move it to the bottom of the collaborators list.
Additionally, if you haven't already, add yourself to the <a href="https://link.gitcode.com/i/37875336800ce6f7d003d9d798c82614" target="_blank">CODEOWNERS</a> file if you wish to take responsibility for reviewing PRs for a language's translations or a specific directory.
流程三：添加新的组织所有者
第 1 步：打开提议 Issue，使用以下模板：
Hi, @username! You've been an active tldr-pages organization member for over 6 months.
Thanks for sticking around this far and helping out!
According to our <a href="https://link.gitcode.com/i/f18b50d1f8e797780ddbb11e613b64a6" target="_blank">community roles documentation</a>, you're now eligible to become an owner in the organization.
That means you will, from now on, be part of the team responsible for performing role changes (like this one!) in the community.
When performing such role transitions, make sure to follow the process described in the <a href="https://link.gitcode.com/i/dfc33de5535dc379426d2513d7fd7ed5" target="_blank">COMMUNITY-ROLES.md</a> document.
Is that OK with you? Let us know!
Either way, thanks so much for all the work you've done so far. You rock!
第 2 步：对方接受邀请后，前往 https://github.com/orgs/tldr-pages/people，将对方的角色从"member"改为"owner"。
第 3 步：建议对方开 PR，把自己的名字移动到 MAINTAINERS.md 的"Organization owners"一节（同样包含 Closes #<issue number>），并把原来的组织成员条目移到成员列表底部。
可复用的回复评论模板：
Welcome to administering tldr-pages! I've converted your role to an Organization Owner.
Feel free to close this issue with a pull request, updating the <a href="https://link.gitcode.com/i/a3cfb6b8b60341264fcfd65abe6e61fe" target="_blank">MAINTAINERS.md</a> file's active organization owners section with a new entry.
Make sure to update your existing <a href="https://link.gitcode.com/i/0bd7af44f163fc221ed8e97c76b8011b" target="_blank">organization member</a> entry in <a href="https://link.gitcode.com/i/b718d59ce680c88daf5efc1fe7f5e047" target="_blank">MAINTAINERS.md</a> file and move it to the bottom of the members list.
As an owner, you will be able to perform role changes and also manage the organization's settings. I request you to be extra careful to avoid any accidental misconfigurations and also discuss any changes beforehand with other maintainers before implementing them.
流程四：移除不活跃的组织成员
第 1 步：打开提议 Issue，使用以下模板：
Hi, @username! As you know, our <a href="https://link.gitcode.com/i/f18b50d1f8e797780ddbb11e613b64a6" target="_blank">community roles documentation</a> defines processes for keeping the list of organization members in sync with the actual maintenance team.
Since you haven't been active in the project for a while now, we'll be relieving you from the maintainer responsibilities.
In practice, not much will change on your side, since you'll remain a collaborator in the repos you have been active in.
That means **you will keep the ability to commit, merge PRs, label and close issues, etc.**, whenever you feel so inclined.
If you don't, that's all right too!
Every bit of work you already did for the tldr-pages project was a voluntary gift of your time to this community, which is deeply appreciated.
Your efforts have contributed to a project which helps hundreds of people every day — be proud of it!
And of course, you're welcome back anytime as an active maintainer, if you so choose — in which case, just let us know and we'll re-add you to the organization, in accordance with the principles of our governance guidelines.
In any case, we wish you the best of luck in your new endeavors!
第 2 步：等待对方确认（或两周内无任何反应）后，前往 https://github.com/orgs/tldr-pages/people，点击对方行内的齿轮图标，选择 "Convert to outside collaborator" 菜单项——这一步恰好与 COMMUNITY-ROLES.md 顶部"必须开启 2FA 才能成为外部协作者或组织成员"的安全要求形成闭环：未通过 2FA 验证的成员会在这一环节被转换。
第 3 步：打开 PR，把对方的名字移动到 MAINTAINERS.md 的"Past organization members"一节，并在 PR 描述中包含 Closes #<issue number>。
前置硬性条件：强安全的两因素认证（2FA）
文档在开头用两个醒目的警示框强调安全前置条件：
[!IMPORTANT] 要被添加为外部协作者或 tldr-pages 组织成员，你的 GitHub 账号必须启用安全的两因素认证（2FA）方式（Authenticator 应用 / 安全密钥 / GitHub Mobile）。
[!WARNING] 基于 SMS 短信的 2FA 方式被攻破的风险更高，因此项目要求所有维护者禁用短信 2FA，改用更安全的方式。
在 MAINTAINERS.md 的历史记录中也可以看到 2FA 强制执行的实例：例如有成员因"Removed during 2FA enforcement"（在 2FA 强制执行期间被移除）或"Removed due to 2FA enforcement, when converting to outside collaborator"（因 2FA 强制要求而在转换为外部协作者时被移除）而离开组织名单，说明这一安全要求是实际执行而非纸面规定。
谁可以变更角色
根据 COMMUNITY-ROLES.md 的"Who can change roles"章节，角色变更的权限设计分为两层：
- 提议层：任何社区成员都可以（且被鼓励）按照上文流程提出角色变更建议；
- 执行层：只有 tldr-pages 组织的所有者才能实际执行角色变更操作（添加协作者、调整成员角色等）。
这与 MAINTAINERS.md 中"组织所有者拥有组织旗下全部仓库的管理员权限，并负责执行社区中的角色变更"的描述完全一致。同时，所有者本人也受制于同一套流程——例如文档要求所有者在执行变更前，应与其他维护者先行讨论，避免意外的错误配置。
角色配套机制：MAINTAINERS.md 名单与 CODEOWNERS 自动审查
角色体系并非孤立存在，它由仓库中的两份配套文件支撑运转：
MAINTAINERS.md：角色的权威记录
MAINTAINERS.md 是角色流转的"落地账本"，按 Repository collaborators（仓库协作者）→ Organization members（组织成员）→ Organization owners（组织所有者） 三段记录人员名单，并附带两个规则：
- 加粗的名字代表当前在任者，未加粗的条目保留作历史记录；
- 每位维护者都记录了加入与（若有）离开的日期及对应 Issue/PR 链接，形成完整的时间线，为"6 个月活跃期""是否重新加入"等判定提供数据支撑。
值得注意的是，文件开头的注解明确要求：所有维护者都应遵循 Maintainer's guide，该指南是维护者日常协作行为的"活标准"——它描述而非规定项目的维护实践，例如：新讨论线程理想上应在 3 天内得到响应；PR 需要 通过自动化测试、解决审查意见、并获得两位维护者批准 才能合并；以及合并时优先使用 Squash and merge 还是 Rebase and merge 的策略选择等。这些细节共同定义了"维护工作"的具体内涵，也支撑了角色晋升标准中"非平凡审查""维护任务"的判定。
CODEOWNERS：审查责任的自动分配
COMMUNITY-ROLES.md 还专门解释了仓库根目录 .github/CODEOWNERS 文件的作用：它允许对 tldr-pages/tldr 仓库有写权限的贡献者，针对特定文件与目录自动接收审查请求通知。贡献者如果愿意，可以自行开 PR 把自己加入该文件。
从仓库实际内容看，.github/CODEOWNERS 的典型条目包括：
/pages.zh/ @BananaaaKING @Ninzero
/pages.de/ @pixelcmtd @gutjuri
/contributing-guides/style-guide.md @sbrl @kbdharun @sebastiaanspeck
/scripts/* @sebastiaanspeck @kbdharun
文档给出的典型使用场景包括（但不限于）：
- 语言专长型：会说某门语言的贡献者，希望协助审查该语言的翻译 PR（例如
/pages.fr/、/pages.ko/对应的审查者）； - 平台专长型：对特定平台有专长的人，希望审查该平台的 PR；
- 规范守护型：有兴趣审查 客户端规范（client specification） 更新的贡献者。
需要强调的边界是：CODEOWNERS 机制纯粹用于 PR 的自动审查请求分发，并不会为被列名的协作者在"代码拥有"文件上增加额外的版权——版权相关事宜以仓库根目录的 LICENSE.md 为准。
在 contributing-guides/maintainers-guide.md 的 PR 处理流程中，CODEOWNERS 还与角色体系产生了直接联动：非英文 PR 若被 CODEOWNERS 自动指派了审查者，至少需要获得其中一位的批准；若数天后仍无审查，首位维护者应 ping 提醒；若超过 10 天仍未获得 CODEOWNERS 的批准，该 PR 在拥有两位批准的前提下可被合并。这套规则将 CODEOWNERS 从"通知机制"升级为"质量把关机制"，也解释了为何角色晋升流程中会反复建议新维护者加入 CODEOWNERS。
结语：一套可自愈的社区治理闭环
纵观 COMMUNITY-ROLES.md 与仓库配套文档，可以看到 tldr-pages 的角色体系是一个完整的闭环：贡献→量化达标→提议→授权→名单更新→持续活跃或退出→（回归）。它以客观可核查的 PR 数量与审查次数为晋升依据，以 MAINTAINERS.md 为人员账本，以 CODEOWNERS 为审查责任分配器，以 2FA 为安全门槛，以 Maintainer's guide 为日常行为基准——所有环节都公开、透明、可讨论，且允许例外。
对于想深度参与 tldr-pages 的贡献者，本文的量化标准即是最直接的路线图：先提交 5 个非平凡 PR 成为协作者，再通过定期审查与合并工作（合并 ≥10 个 PR、审查 ≥5 次）成为组织成员，保持活跃 6 个月后即可晋升为所有者；而对已经是组织所有者的读者，上文四套模板与操作路径则提供了开箱即用的执行手册。无论你身处哪一级，这套体系的设计初衷始终如一：让角色的变更如实反映实际工作，而非制造新的权力层级。