贡献者行为准则如何制定

本文目录导读：

1. 第一阶段：明确动机与范围（定调）
2. 第二阶段：选择/自定义权威模板（参考）
3. 第三阶段：核心内容框架（起草）
4. 第四阶段：流程与执行（落地关键）
5. 第五阶段：发布与沟通
6. 常见误区（避免踩坑）
7. 推荐工具与资源
8. 最后：一句话总结

制定一份有效的贡献者行为准则（Code of Conduct, CoC），不仅仅是起草一份文件，更是一个建立社区信任、明确行为边界的过程，以下是分步骤的制定指南,结合了开源社区和企业内部协作的最佳实践。

第一阶段：明确动机与范围（定调）

在动笔之前,先问自己三个问题：

1. 目标是什么？ （减少新人融入障碍、防止骚扰、维护专业讨论环境、保护项目声誉）
2. 社区/项目规模与性质？ （大型开源项目 vs. 小型内部团队，技术社区 vs. 内容共创社区）
3. 若被违反，谁负责执行？ （项目维护者、社区经理、或独立委员会）

产出： 一份一两页的简短声明，描述社区希望营造的氛围（如“友好、尊重、专业”）。

第二阶段：选择/自定义权威模板（参考）

不建议从零开始写，直接使用经过法律和社区验证的模板，并根据自身情况微调,最常用的几个：

• 贡献者盟约（Contributor Covenant）v2.1：GitHub、Linux、Kubernetes 等数万项目采用，结构清晰，覆盖全面，是最推荐的开源社区起点。
• Mozilla 社区参与指南（Mozilla Community Participation Guidelines）：非常详细，适合大型复杂社区,包含强制仲裁流程。
• Django 行为准则（Django Code of Conduct）：以其严格的执行流程（独立委员会、上诉机制）著称。
• Geek Feminism 社区反骚扰政策（Geek Feminism Anti-Harassment Policy）：聚焦于消除骚扰,特别是针对边缘群体。

修改要点：

• 如果你使用 Contributor Covenant：
  • 保留其“我们的承诺”、“标准”、“责任”等核心章节。
  • 在“范围”中明确：是否覆盖线上、线下活动（如聚会、峰会）。
  • 必须定义“项目代表”是谁（是维护者、还是社区经理？）。

第三阶段：核心内容框架（起草）

一份完整的行为准则通常包含以下 6 个部分：

我们的承诺（Our Pledge）

简明扼要地宣誓：我们致力于为每个人提供无骚扰的协作体验，无论其身份、背景、经验水平等。

标准（Standards）—— 最需细化部分

这是争议的源头，必须具体、可操作。

• 可接受行为（示例）：
  • 使用欢迎和包容性的语言。
  • 尊重不同的观点和经验。
  • 优雅地接受建设性批评。
  • 专注于对社区最有利的事物。
  • 对其他社区成员表示同理心。
• 不可接受行为（示例）：
  • 禁止：性语言、侮辱、人身攻击。
  • 禁止：公开或私下的骚扰（包括不恰当的玩笑、持续的打断、不受欢迎的性关注）。
  • 禁止：暴露他人的私人信息（doxxing）,除非获得明确许可。
  • 禁止：其他专业合理的、被认为不适当的任何行为（此条可在极端情况下兜底，但需谨慎使用）。

执法责任（Enforcement Responsibilities）

这是最容易被忽略但最关键的部分。

• 谁负责？ （项目维护者、一个专门的“行为委员会”）。
• 他们有何权力？ 他们可以编辑、删除违规评论/PR；暂时或永久封禁违规者。
• 首次违规如何处理？ （警告 → 已读不回 → 临时封禁 → 永久封禁）。

范围（Scope）

本准则何时适用？

• 在项目的代码仓库、讨论区、Issue、PR中。
• 在代表项目参与的公开场合（如官方会议、社交媒体账号）。
• 建议：明确写明 “在项目之外的不当行为，如果严重影响社区成员，也可能被视为违反本准则” （这能有效防止外部骚扰者利用规则漏洞）。

执法方（Enforcement）—— 提供举报渠道

• 清晰列出举报方式：特定的电子邮件地址（如 conduct@yourproject.org）、一个安全问题报告链接（如 GitHub Security Advisory）、或一个匿名的第三方平台（如 Citadel）。
• 明确承诺：所有举报将得到严肃且保密的审查和调查。
• 避免：使用个人社交账号、非公开的群聊作为举报渠道,因为这会导致偏见和泄露风险。

归属（Attribution）

通常放在最后，感谢和引用来源（“本行为准则改编自贡献者盟约 2.1”），这不仅是形式,更溯源了所有权和许可。

第四阶段：流程与执行（落地关键）

没有执行的行为准则只是一纸空文。你需要一套简单的流程：

1. 接收举报：指定专人（最好2-3人，避免单点失效）。
2. 初步评估：是否在本准则范围内？是否真实？是否恶意举报？
3. 调查与决议：联系双方当事人，收集证据（截图、聊天记录）,根据严重程度决定处罚。
4. 通知与上诉：将决定（附理由）通知举报人和被举报人。提供上诉渠道（向项目的更高层维护者或独立仲裁员申诉）。

建议：为“维护者”准备一份 执法指南（Enforcement Manual）—— 这是一份内部文档，详细说明警告怎么写、封禁多久、如何记录案例等，Contributor Covenant 官方就提供这份指南。

第五阶段：发布与沟通

1. 合并到项目根目录：将文件命名为 CODE_OF_CONDUCT.md，放在仓库根目录下，GitHub 会自动识别并显示。
2. 公开宣传：在 README、项目文档、贡献指南（CONTRIBUTING.md）中链接到该准则。
3. 所有协作者必须确认：如果是新社区，可以要求新贡献者在提交 PR 前签署确认；如果是现有社区,发公告说明即日起生效。
4. 定期回顾：每年或当社区规模发生重大变化时,修订一次。

常见误区（避免踩坑）

• “我们社区很和谐，不需要”：往往等到出现严重冲突才想起制定，为时已晚,预防优于处理。
• “太短了写不全” vs. “太长没人看”：平衡点是清晰，3-5页的 CODE_OF_CONDUCT.md 是比较合适的长度。
• “只规定正面行为，不规定禁止行为”：那会让人困惑（“什么算‘不尊重’？”）。必须黑白分明地列出禁止项。
• “只针对贡献者”：同样适用于维护者,维护者更应以身作则。
• “执法标准因人而异”：切忌，所有案例应按照相同标准处理,否则准则会完全失效。

推荐工具与资源

• 选择模板：直接使用 Contributor Covenant Template Generator 生成初始文本,再根据社区特点自定义。
• 内部指南：参考 GitHub 的 社区健康文档 和 行为准则执行指南。
• 法律意见：如果项目涉及企业赞助或敏感领域,建议请法务或通晓社区规范的律师过目。

一句话总结

好的行为准则是“一个平等、尊重的基础设施的蓝图” —— 它告诉所有人：我们珍视哪些人，我们不允许哪些事，以及当事情发生时，谁来按规则处理，花时间制定它、定期复习它、公平执行它,你的社区才能健康生长。