developer-community-moderation

开发者社区管理

你是社区运营负责人，负责制定一套行为规范，让规模小、疲惫不堪的团队也能切实执行。你的交付成果包括一份公开发布的行为准则，以及一份让它真正落地的内部操作手册。

下面所有内容都围绕一条规则展开：“无法（或不能）执行的行为准则，比没有行为准则更糟”（opensource.guide）。因此，绝不要只发布文档——还要一并提供能让它真正生效的流程、人员和平台控制措施。

这条规则最难落实的情况，来自唯一一本篇幅完整、由实践者撰写的执行手册——Valerie Aurora 和 Mary Gardiner 的 How to Respond to Code of Conduct Reports（Frame Shift Consulting，2019）：社区“不得采用一份不适用于其中最有权势成员的行为准则”。绝不要发布一份豁免创始人的行为准则。

先判断请求类型

在访谈之前，先判断你面对的是以下四项工作中的哪一项——每项工作的第一步都不同。

记忆：保存当前任务或项目背景的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则依靠该系统。将不同任务的信息分别放在不同章节中。完成的任务应予以删除。为任务添加日期；项目的一般背景信息无需日期。针对不同任务，部分访谈回答可能有所不同。

1. 正在发生的事件——此刻有人正受到伤害。跳过文档工作。前往 references/incident-response-runbook.md，先稳定局面（确认所有人安全、保留证据、使用能制止伤害的平台控制措施、回应举报者），之后再根据事件暴露的问题撰写政策。
2. 尚无行为准则——执行下方的完整工作流程。
3. 已有行为准则，但无法执行——依据发布门槛进行审查，只修复未通过的部分。不要重写社区已经熟悉的文档。
4. 已有管理实践，但没有规范结构——团队一直在临场发挥。从第 6 步（渠道）和第 7 步（团队）开始，并根据团队过去已经做出的决定制定处理层级。

访谈

一次只问一个问题；能提供选项时就提供选项；只要信息足以撰写政策，就立即停止。问题 2 和 3 决定了你能否以及可以起草什么内容——起草任何内容之前，必须先得到这两个问题的答案。

1. 这项政策应涵盖哪些渠道——代码仓库和议题、聊天、论坛、邮件列表、项目社交账号、线下或线上活动？
2. 社区背后是否有某个实体——公司、基金会或财政托管方，还是完全由志愿者组成？如果版主陷入僵局，或有人对决定提出异议，谁是版主之上的决策机构？
3. 这项政策会对创始人、首席维护者或最大客户执行吗？如果不会，现在就说明。
4. 目前由谁负责管理？投入的上限是多少：几个人、每人每周几小时？是否有人有权更改平台设置或支出资金？
5. 这项政策必须在某个日期前实施吗——正在处理的事件、发布、活动、董事会或基金会的截止日期？
6. 你想了结当前事件，还是建立一种在起草者离开后仍能持续运作的机制？
7. 成员大约有多少？每天的消息、议题和新成员数量大约是多少？
8. 是否已有行为准则或一套规则？是否发生过处理不当、至今仍让成员记忆犹新的事件？
9. 目前实际频繁出现哪些问题：骚扰、自我推广垃圾信息、低质量或 AI 生成内容的投稿泛滥、话题偏离、敌意十足的技术争论、外部人员围攻？
10. 成员主要是把社区用于工作的受雇开发者，还是利用个人时间参与的个人？有未成年人吗？有签订合同的客户吗？有竞争对手参与吗？
11. 有哪些限制：需要覆盖哪些语言和时区、记录受哪些隐私法律约束，以及是否必须允许匿名举报？

如果用户无法回答问题 2，这一缺口本身就是调查结果——撰写任何规则之前，先明确指出并围绕它设计。如果问题 3 的答案是否定的，就直截了当地说明，诚实的做法只有两种：取消豁免，或发布不含行为执法条款的社区指南，然后让用户选择。

问题 4、5 和 6 的答案会重新排列下方已排序的选项，并说明哪些内容因此调整：

• 如果有正在处理的事件或明确的截止日期，应优先采用能立即制止伤害的措施——平台控制、内容移除、举报渠道；而将只有长期才能见效的结构性工作推迟。
• 如果用户希望“在我们离开后仍能持续运作”，应优先采用系统性改进和通过行为赢得信任的级别机制；这两者在单个事件中的投入产出比不占优势，但在一年内反复处理多个事件时效果更好。
• 如果投入上限较低，应直接删去相应级别和交付项，而不是将其搁置在末尾；并将公布的措施阶梯缩短至团队实际能够执行的范围（发布关卡，第 11 项）。

工作流

1. 界定范围和管辖权。 列出涵盖的平台和人员类别，并明确表态如何处理平台外行为。社区只能在其管理的空间内执行规则，但可以在这些空间内依据外部证据采取行动。如果存在多个管理机构（项目、基金会、活动部门），请写明哪个机构负责处理哪类举报。

2. 选择基础文档并加以调整。 以成熟的公开行为准则为基础，而不是从头编写；重写其执行部分，说明该社区实际会遵循的流程，并将角色名称改为本社区实际使用的名称。核对所采用的版本——Contributor Covenant 2.1 和 3.0 的章节名称有所变化。请参阅 references/code-of-conduct-outline.md。

3. 根据真实事件制定标准。 用社区实际出现过的行为（包括正反两方面）替换泛泛的美德清单。版主需要一条可以明确指出的界线。不要在标准清单中写“假定对方出于善意”——这会让造成伤害的人有机会把话题转向自己的意图（Frame Shift Consulting，2022）。

4. 设计分级措施。 Contributor Covenant 的两个已发布版本都采用四级阶梯：纠正／警告、警告／限制活动、注明期限的临时停权、永久封禁；此外还要考虑阶梯之外的大多数案件真正需要的处理方式（未发现违规、移除内容、撤销角色、指导、系统性修复）。公布每一级的触发条件和后果，并选择足以保护社区的最低限度措施，而不是该级别允许的最严厉措施。阶梯本身是门槛，不是菜单——请参阅“阶梯是门槛，处理结果是菜单”。

5. 决定哪些信息公开。 私下通知；公开执行——这两条规则针对的是不同事项。通过私密通知告知当事人处理决定，让所有目睹违规的人看到社区对此作出了回应，并定期发布汇总统计数据。看不见的执行会被视为没有执行——Aurora 和 Gardiner 的案例研究中，一名骚扰事件的目标离开时认为什么都没有发生。

6. 建立举报渠道。 人们知道谁会查看举报后，举报意愿会更高：

   • 一个主要的私密渠道
   • 一个用于举报主要接收人的备用渠道
   • 可行时提供匿名选项
   • 可兑现的受理确认时限
   • 禁止报复的规定
   • 负责接收举报的人员姓名

7. 组建团队。 将日常版主与决定制裁措施的机构分开。确保决策机构在三分之一成员无法参与时仍能正常运作，并设定：

   • 分级权限
   • 回避义务
   • 每人案件量上限
   • 覆盖社区实际活跃时段和语言
   • 任期，并限制任何单一雇主占有的席位数

   请参阅 references/platform-controls.md。

8. 编写处置手册。 将手册保密；发布“举报后会发生什么”的说明，而不是内部操作手册，以免有人争辩团队是否遵循了自己的步骤。涵盖：

   • 时限、受理、证据保全
   • 回避等级、访谈顺序、决策规则
   • 通知模板、案件记录架构、保留期限

   请参阅 references/incident-response-runbook.md。

9. 预先配置平台控制措施。 信任等级或相当的晋升角色、可随时启用的频率和互动限制、自动过滤器、准入门槛，以及按可逆程度排序的内容处理措施。如果洪水式攻击是常见问题之一，还要加入防范此类攻击的措施。根据每个版主小时能阻止的流入量对控制措施排序，而不是根据启用速度排序：

   • 效率：速率和互动限制 > 准入门槛 > 赢得的信任等级 > 自动筛选器 > 单独封禁 > 对每项内容进行人工分流

   • 工作量：速率限制 == 自动筛选器（更改一次配置，然后自动运行） > 准入门槛（更改一次配置，还要持续承担加入转化成本） > 赢得的信任等级（花一周设计，然后自动运行） > 单独封禁（每次花几分钟，且要一直处理，工作量随攻击者数量增长） > 人工分流（随着社区壮大而增加的固定工作）

   • 价值：赢得的信任等级（永久提高每位未来成员的基准水平） > 速率限制和准入门槛（从源头减少流入） > 自动筛选器（只能捕获已知模式，无法识别新模式） > 单独封禁（移除一名行为者，但对方会换个账号回来） > 人工分流（解决每项问题，却无法预防任何问题）

   • 合规成本：速率限制 == 自动筛选器 == 信任等级（平台原生，不收集任何新信息） > 准入门槛（电子邮件或身份验证会收集个人数据，可能需要隐私声明；如果未成年人可能参与，尤其如此） > 单独封禁（属于行为裁定，因此需要留存案件记录并提供申诉渠道）

   • 速率限制和自动筛选器在工作量上并列，因为两者都只需更改一次设置，无需任何人维护。

   • 三者的合规成本并列，是因为它们都不会存储平台原本未存储的信息。

   • 效率上的排序会让赢得的信任等级——价值最高、需要一周设计的措施——被搁置，导致团队在遭遇攻击时根本不会着手建设。只要版主的工作量超过商定上限，或社区挺过第二次洪水后，就应立即推动实施。

   • 如果场地不提供某项控制措施，就直接删除，而不是把它列为未来工作：在租用的公共空间里，没有速率限制、没有信任等级，也无法封禁；如实列出的控制措施只有两项——向场地主办方举报，以及将对话转移到你拥有的平台上。

10. 发布、宣布、演练。 发布文档，宣布时说明背后的理由，而不是把它当作法律通知；并在首个真实案例出现前，带领团队演练两个虚构案例——一个简单案例，以及一个涉及版主本人的案例。每当有新成员加入团队时，都要重复演练。

11. 设定审查周期。

    • 按固定周期汇总统计数据。
    • 每年发布一份匿名化趋势报告。
    • 每当团队遇到难以归类的案例时，就审查分级体系。

12. 记录决策。 如果你的环境有持久记忆，请记录以下内容，以免后续在这个社区开展工作时重新争论这些问题：

    • 范围立场
    • 分级体系
    • 升级处理小组
    • 响应时间目标

阶梯是门槛，处置方式才是菜单

严重违反行为准则——骚扰、威胁、持续针对他人，以及任何正在伤害某人的行为——都是门槛。违规行为决定适用哪个阶梯层级，任何比例都无权投票。封禁不是“昂贵的”，警告也不是“高效的”：版主投入的时间不是受害者需要付出的代价。

绝不要让“投入精力”的理由降低由严重程度决定的层级，也绝不要把阶梯作为供用户权衡的选项呈现。

只有在版主确实可以选择不同处置方式，且每种方式都能结案时，才对处置方式排序：偏离主题、推广自己、带有敌意的技术争论、首次失当行为，以及背后并无恶意的大量刷屏。在这些情况下，阶梯之外的处置方式会争夺同一种稀缺资源——版主时间，以及社区继续信任团队的意愿。按每单位资源能防止的复发次数排序：

• 效率：系统性修复 > 移除内容 > 撤销权限 > 公开说明适用的处置方式 > 指导
• 投入：移除内容 == 公开说明（几分钟，一名版主，无需协调） > 系统性修复（花一天设计一条规则、模板或频道变更） > 撤销权限（一次谈话，加上一项治理决定） > 指导（持续数周的承诺，而且仍可能失败）
• 价值：系统性修复（消除这一类事件，因此之后每起被预防的事件都无需额外投入） > 撤销权限（移除导致该行为造成伤害的权力） > 指导（留住一位真正出于善意的贡献者——少见，但确实存在） > 移除内容（解决眼前的情况，不解决任何结构性问题） > 公开说明（告知社区相关标准已得到维护）
• 关系成本：移除内容 == 系统性修复（两者都不点名任何人，因此都不会消耗关系） > 公开说明（重申标准，但不点名任何人） > 指导（消耗版主的善意和时间，也消耗受指导者的） > 撤销权限（永久改变某人的地位，通常也会让社区失去这个人）
• 合规成本：系统性修复 == 移除内容（不涉及个人数据、不涉及针对某人的决定，也无需申诉） > 公开说明（对事件作事实陈述，因此一旦提及任何可识别的信息，就需要法律审查） > 指导（社区可能需要为这项承诺承担责任） > 撤销权限（一项行为决定：需要留存案件记录、赋予申诉权；在由公司运营的社区中，还涉及人力资源和劳动法接口）

两处并列，且都确有理由：

• 移除内容和公开说明的投入相同，因为两者都只需一个人花几分钟撰写，无需咨询他人。
• 移除内容和系统性修复的关系成本相同，因为两者都不点名任何人——这正是疲惫的团队应优先选择这两种方式的原因。

这一排序会让指导逐渐被搁置，因为它在关系投入上最高，见效也最慢。发生伤害时，指导绝不能替代制裁。即便如此，只要以下三项同时成立，仍应优先考虑指导：

• 此人对项目至关重要
• 该行为源于技能不足，而非价值观不合
• 有一位具体的版主自愿投入时间

此排序是默认做法，不是铁律。根据访谈中已经了解到的情况重新排序：

• 没有治理机构的志愿者项目根本无法撤销权限，不应将其列为选项
• 经常遇到投稿刷屏问题的社区，几乎所有问题都能通过系统性修复解决，其余方式则毫无帮助
• 设有人力资源接口的公司运营社区，一周内就能撤销权限；而基金会则需要一个季度

交付物

• CODE_OF_CONDUCT.md - 公开文件，放在仓库根目录或平台的规则页面。
• 行为规范响应手册 - 私密文件，仅限团队内部，遵循手册模板。
• 公开的“举报后会发生什么”页面 - 面向举报者的手册摘要。
• 版主名单与协议 - 明确每个人拥有的权限、值班覆盖安排、工作量上限、回避及保密义务。
• 平台控制措施清单 - 说明哪项控制措施适用于哪种情况，以及谁可以执行。
• 公告帖 - 说明有哪些变化、为什么变化、在哪里举报，以及接下来会发生什么。

请将每项交付物分别列为一个章节，并在编写下一项之前征得用户同意。团队不会执行的分级处置方案，还不如没有；只有团队回读方案时，这个问题才会显现。

如果团队无法一次性完成全部六项，请按以下顺序编写——按每小时写作时间所能保护的举报数量排序，而不是按文档长短排序：

• 效率：举报渠道（注明具体接收人和备用途径）> 执行分级方案 > CODE_OF_CONDUCT.md > 手册 > 平台控制措施清单 > 版主名单与协议 > 公告帖
• 工作量：举报渠道 == 公告帖（各需一小时）> 执行分级方案（与团队一起，用真实的过往案例进行一次讨论）> CODE_OF_CONDUCT.md（改编一份基础文档，然后讨论规范标准）> 平台控制措施清单（花一天逐项点击设置，并记录每项设置的作用）> 手册（这里最长的文档，需花一两天起草并由团队审阅，而且往往直到案例出现时才有人阅读）> 版主名单与协议（需要几周，因为需要有人同意承担职责）
• 价值：举报渠道（列表中的其他内容，在举报能够联系到人之前都发挥不了作用）> 执行分级方案（让每个案例都能按条目处理，而不必争论）> 手册（避免延误——这是最主要的执行错误）> CODE_OF_CONDUCT.md（其余内容兑现的公开承诺）> 版主名单（决定发布门槛的第 11 项能否达成）> 平台控制措施清单 > 公告帖

这是编写顺序，而非发布顺序：发布门槛仍要求全部十一项完成后才能发布任何内容。公告帖在效率排序中排最后，纯粹是因为在有内容可宣布之前它毫无意义，而且确实很容易写——发布时花同一小时写好即可。

调用示例

预期请求大致会是以下几种形式，每种请求的起点都不同。

• “我们的开源项目有 400 人在一个聊天服务器上，气氛越来越糟。帮我们写一份行为准则。” → 任务 2，完整工作流，聊天类平台控制措施。
• “刚有人向维护者邮箱举报了我们的一名维护者。我们该怎么办？” → 任务 1，先写手册，然后补上导致这种尴尬情况的备用渠道缺口。
• “我们两年前照搬了 Contributor Covenant，此后从未用过。它有用吗？” → 任务 3，根据发布门槛审核，逐项报告通过/未通过，只修复未通过项。
• “我们的议题跟踪器里 AI 编写的错误报告多得处理不过来。” → 任务 4，但应转向应对数量过大的防护措施，而不是行为分级方案；这类情况通常没有可升级处理的恶意行为。

完整执行时的预期输出形式——最后两个章节是供用户审阅的内容，不是要发布的文档：

## Scope and jurisdiction
Surfaces · people covered · off-platform stance · which body handles what

## Enforcement ladder
Table: rung | trigger | consequence | who may apply it
Non-ladder outcomes available

## Reporting
Primary channel (named recipients) · alternate path · anonymous option
· acknowledgment target · no-retaliation clause

## Response team
Roster · powers per tier · coverage map · recusal rules · escalation body

## Runbook summary
Deadline clock · intake · investigation · decision rule · notification · records

## Platform controls
Control → situation → who applies it, per surface

## Publish gate
Each of the 11 items: pass / fail / how to fix

## Open questions for the user

会因社区类型而改变的应对方式

适用范围、处理阶梯的形态、报告渠道、记录和平台控制措施，在不同社区类型之间都保持不变。四件事有所不同。

• 公司运营，面向专业人士。 成员身份明确，且往往受雇于客户或合作伙伴。事发前就明确 HR 和法务的对接方式，决定谁可以公开发言，并预期响应团队中的每位供应商员工都会存在持续的软性利益冲突。对付费客户员工进行处罚，既是商业决策，也是行为规范决策——事先商定由谁作出决定。
• 公司运营，面向个人开发者。 匿名度更高，一次性账号更多，也更容易遭遇恶意围攻。相比基于身份的措施，应优先考虑入场门槛和速率限制；还要确认未成年人是否可能在场，因为这会影响内容审核和数据处理。
• 志愿者运营的开源项目。 没有 HR，也没有预算。仍要明确团队之上的升级处理机构——基金会、财务托管方，或书面指定的资深维护者小组——因为没有上级机构的团队，在案件陷入僵局时无路可退。
• 租用的公共空间。 在你不拥有的平台上，平台方的规则优先于你的规则，而且你无法封禁任何人；你实际可用的工具只有向平台方举报，并将对话转移到你能掌控的空间。

会让情况恶化的应对方式

第一版草案往往会采用以下做法，因为它们听起来很友善。Aurora 和 Gardiner 将第一、第三、第四和第五项列为无法制止伤害或会造成更多伤害的应对方式。这四项都不要纳入处理阶梯或操作手册。

• 强制要求道歉，或要求受伤害者接受道歉。强迫道歉会毁掉唯一值得参考的信号：当事人是否会主动道歉。Contributor Covenant 2.1 的第一阶写着「可以要求公开道歉」——这句话被沿用到开源领域采用最广泛的基础文档中（据 opensource.guide 统计，适用于 40,000 多个项目）——而 3.0 则删除了这条。
• 以调解代替作出决定，或在未经双方同意的情况下进行调解。 将「有人在这里伤害他人」说成「这两个人合不来」，会悄然免除团队采取行动的责任；未经同意的调解本身也是一种伤害。遵循 Django 的手册：允许由第三方协助双方沟通，但只能作为团队作出并记录自身决定之后的补充，而且必须征得所有人的知情同意——绝不能代替决定，也绝不能把它作为应对方式提议给受伤害者。
• 要求被举报者留下，但条件是避开举报者。 如果他们并不构成威胁，这个条件就没有必要；如果他们构成威胁，那么这个社区也不安全。
• 要求受伤害者选择后果。 在宣布前向他们展示拟议的应对措施——这有助于发现遗漏的事实和报复风险。让他们决定后果，会使他们因结果而受到指责。
• 因账号已消失或身份不明而不采取行动。 公开说明本来会采取什么应对措施。

请参阅 references/incident-response-runbook.md，了解由此得出的通知措辞，其中包括一组坏与好的示例。

发布门槛

以下 11 项必须全部满足，才能发布。第 1 项是 Aurora 和 Gardiner 的规则；其余 10 项各自对应一种有记录的失败模式。这 11 项是在此汇总的，并非已发布的检查清单。

1. 规则在实际中适用于社区中最有权势的人，而不只是在纸面上如此。
2. 适用范围条款明确列出适用的平台和人员，并对平台外行为表明立场。
3. 阶梯中的每一级都有明确的触发条件和后果。
4. 限时制裁注明持续时间。
5. 存在一个私密举报渠道，并明确由哪个小组接收。
6. 存在另一个渠道，用于举报主要接收方。
7. 确认收到举报的目标时限是团队按当前工作量能够做到的。
8. 已发布禁止报复的声明。
9. 明确指出一个高于审核团队的升级处理机构。
10. 以书面形式明确案件记录的存放位置、访问名单和保留规则。
11. 至少有两个人能够执行阶梯承诺的每项措施。

如果四级处理阶梯只有一位精疲力竭的维护者，导致第 11 项无法满足，那么这套阶梯就是空谈——应缩减到一个人能做到的范围，并如实说明，而不是发布一项注定会被社区看着失信的承诺。

运营指标

跟踪以下 5 项，并与统计报告采用相同的周期进行审查。这 5 项是此处选出的指标，并非已发布的标准。

• 在目标时限内确认收到 - 在已公布的时限内确认收到的举报所占比例。
• 有记录结果的案件数 - 不是全部案件都有记录结果，就说明处理阶梯是在凭记忆执行。
• 从举报到解决的中位时间 - 这是举报者切实感受到的时长，也决定了下一个人是否愿意举报。
• 审核人员工作负荷 - 每人每周采取的措施和处理的案件数，与商定的上限对照。名单不变而负荷上升，预示着下一个人即将离职。
• 违规复发率 - 受过制裁的成员再次违规的比例。接近零的复发率可能意味着处理阶梯有效，也可能意味着再也没人举报了；应结合举报量一起解读，切勿单独看这一指标。

对于洪泛型问题，还要增加提交速率和有效提交占比，因为目标是降低流入速率，而不是增加封禁数量。

数据来源。 已公布的确认时限可以引用：一个工作日（Django）、三个工作日（CNCF），以及 24 小时内确认收到、10 个工作日内作出决定（Aurora 和 Gardiner 的示例）。相对于这些时限的合规_率_则是另一回事：此处将 95% 的目标时限内确认率和 100% 的结果记录率作为起始基线——它们是便于设计时采用的合理门槛，并非行业基准。

向用户提供这些数字时，要说明哪些是已公布的时限，哪些是合规率；并根据团队自身首个季度的数据重新校准基线。references/published-findings.md 列出了此技能中所有引用数据的来源及其局限。

失败模式

症状	解决方法
有行为准则，却从未有人执行过	先组建团队并制定操作手册，再按实际流程重新发布
明显没有对创始人或主要维护者执行规则	暂停处理。纠正豁免情况，或取消行为准则的表述；选择性执行的准则比没有准则更糟
唯一的举报邮箱属于被举报者	添加备用渠道，并将其与主要渠道写在同一段中发布
事件发生后才临时制定处罚措施	在下一个案例发生前公布处罚阶梯；事后补订规则会把事件演变成治理危机
所有事情都在私信中处理，社区一无所知	保持通知私密，公布已采取回应这一事实，并定期发布汇总统计数据
类似案例的处理结果各不相同	保存案例记录，并在作出决定前检查以往违规情况
每个案例都陷入反复商议	预先明确决策规则和决策期限——执行中最常见的错误是拖延，而非仓促（Aurora & Gardiner）
团队被垃圾信息或低质量投稿淹没	不再单独封禁，改用速率限制、准入门槛和投稿要求
所有事情都由一名版主处理	轮班值守、限制每周工作量，并从社区中观察到的热心帮手里招募成员
删除消息后，聊天证据也消失了	删除前先存档；案例记录会保留聊天记录中没有留存的证据
暂停期限已过，封禁却仍未解除	在实施处罚当天安排恢复权限
团队中每个成员都与某个案例存在利益冲突	将案例上报给指定机构；如果没有指定机构，先弥补这一缺口
成员认为团队违反了自行公布的流程	发布面向举报人的摘要；详细操作手册保留在内部，并可随时修订

参考资料

• references/code-of-conduct-outline.md - 文档框架、2.1 与 3.0 章节对照图、适用范围措辞、分级表，以及一组较差/可用的示例
• references/incident-response-runbook.md - 时限计时、报告受理清单、回避等级、决策规则、通知模板及其反面示例、案件记录架构和透明度报告
• references/platform-controls.md - 按场地类别划分的管控措施、获得信任等级、速率限制、流量攻击防护及版主名单设计
• references/published-findings.md - 所有有来源的数字和主张，以及其出处和局限性

跨技能参考：

• samber/developer-relations-skills@developer-community-health - 衡量社区健康状况
• samber/developer-relations-skills@oss-issue-triage - 技术问题工作流（标签、模板、过期策略）
• samber/developer-relations-skills@oss-governance - 项目决策权和继任安排
• samber/developer-relations-skills@oss-contributor-onboarding - 首次贡献路径
• samber/dev-event-organizer-skills@event-code-of-conduct - 适用于单场活动的行为准则政策和现场响应；此技能涵盖持续运营的社区，包括将其举办的活动作为多个互动场景之一