2026 年 2 月到 4 月，Django 用三个月走完了一条不少项目想走却迟迟没走的路——把 Contributor Covenant 3 纳为官方行为准则，同时附带一套量身定制的执行手册。这不是贴个文本就完事的表面功夫，背后是社区提案、PR 公开评审、工作组实战经验复盘的完整流程。
Contributor Covenant 3 到底改了什么
行为准则从 1.x 到 3，核心思路从"别故意伤害别人"转向"伤害发生了就得修"，几处关键变化：
- 影响优先于意图——哪怕没有恶意，造成的影响也需要被正视和补救。旧版本容易陷入"我不是故意的"辩护循环，新版本直接把焦点放在受害方体验上。
- 明确边界与同意——社区成员声明的边界必须被立即尊重，不存在"再讨论一下"的缓冲地带。
- 覆盖新型骚扰模式——sea-lioning（假装理性追问实则消耗对方精力）、协同骚扰、微冒犯，这些在旧版里要么没提要么表述模糊，现在有了具体定义。
- 执行、透明、问责的指引更清晰——不再是"出了事再说"，而是提前规定怎么处理、怎么公开结果、怎么追责。
对维护者来说，这些变化意味着一件事：准则不再只是墙上标语，而是有操作手册的执行框架。
Django 的定制增强
直接搬 Contributor Covenant 3 的文本并不够。Django 工作组在基础文本上加了五条项目级补充：
| 增强项 | 实际解决什么问题 |
|---|---|
| 线下活动联络人要求 | DjangoCon 等现场活动必须有明确的 CoC 联络人，不是"有就行"而是"必须提前指定并公开" |
| 关联项目范围澄清 | 使用 Django CoC 的子项目、本地社区，边界和期望写清楚，避免"我们引用了但没说清楚管到哪" |
| 恶意举报防护 | 防止举报机制本身被武器化——用 CoC 流程去骚扰别人，本身也是违规 |
| 工作组间分歧升级路径 | 不同工作组对同一事件判断不一致时，有明确的升级程序，不是靠私下协调 |
| 执行透明度提升 | 统计数据和处置结果定期公开，让社区看到准则确实在运转 |
这些补充不是凭空设计，而是工作组从过去几年实际执法中提炼出来的痛点。线下活动联络人缺失、关联项目范围模糊、举报被滥用——都是踩过的坑。
三步走：不是拍脑袋决定的
整个采纳过程拆成三步，每一步都通过 PR 公开评审：
- 2026 年 2 月：建立社区驱动的提案与评审流程——先定"怎么改"，再改内容。
- 2026 年 3 月：更新执行手册、举报指南、FAQ，对齐 Covenant 3 的要求，同时融入工作组经验。
- 2026 年 4 月：正式采纳 Contributor Covenant 3 + Django 增强条款。
每一步的 PR 都在 GitHub 上开放讨论，社区成员可以提 issue、评论、在论坛里辩论。这种"先定流程再定内容"的做法值得其他项目借鉴——流程本身也是治理的一部分。
给自己项目落地 CoC 的实操清单
如果你维护一个开源项目，想采纳或升级行为准则，下面是一个可以直接跑的社区健康文件初始化脚本，把 Contributor Covenant 3 的模板拉到你的仓库里：
# 1. 创建社区健康文件目录（GitHub 会在 org 级别读取 .github 仓库的默认文件）
mkdir -p .github && cd .github
# 2. 下载 Contributor Covenant 3 的最新中文版（也有英文版，替换语言代码即可）
curl -L https://www.contributor-covenant.org/version/3/0/code_of_conduct/zh.md \
-o CODE_OF_CONDUCT.md
# 3. 确认文件已下载
head -5 CODE_OF_CONDUCT.md
# 4. 提交到仓库
cd ..
git add .github/CODE_OF_CONDUCT.md
git commit -m "adopt Contributor Covenant 3 as project CoC"
git push
下载完成后，你还需要做几件事——这些是 Contributor Covenant 3 要求但模板不会自动替你完成的：
# .github/CODE_OF_CONDUCT.yml — 项目级 CoC 元数据（自定义部分）
# 这个文件不是 Covenant 官方格式，但可以作为你的执行配置参考
project: my-django-app
coc_version: "3.0"
language: zh
# 举报渠道 — 必须填写，Covenant 3 要求项目明确指定
reporting:
email: conduct@example.com
# 如果有独立页面，填写 URL
# url: https://example.com/conduct/reporting
# 执行手册链接
enforcement_manual: https://example.com/conduct/enforcement-manual
# 线下活动联络人（如果你有 meetup / conference）
event_contacts:
- name: 张三
email: zhangsan@example.com
role: CoC 联络人
# 恶意举报条款 — 建议显式声明
bad_faith_reporting_policy: |
利用举报流程对他人进行骚扰或报复，本身构成行为准则违规。
工作组有权对恶意举报者采取与普通违规相同的处置措施。
上面的 YAML 不是 GitHub 的标准社区健康文件格式，但可以作为项目内部治理配置的参考。真正生效的是 CODE_OF_CONDUCT.md 文件内容加上你在项目 README 或网站上的举报渠道声明。
落地检查清单：
- [ ] CoC 文件已放入
.github/或仓库根目录 - [ ] 举报邮箱或页面已填写且有人值守
- [ ] 执行手册已写好（至少覆盖：谁处理、怎么调查、可能的处置结果）
- [ ] README 里加了 CoC 链接（
[Code of Conduct](CODE_OF_CONDUCT.md)） - [ ] 如果项目有线下活动，联络人已指定并公开
- [ ] 恶意举报防护条款已写入执行手册
采纳的代价与边界
Contributor Covenant 3 不是万能药。几个现实考量：
- "影响优先于意图"在执行上比看上去更难——判断影响需要倾听受害方，但不同人对同一行为的感受可能截然不同，工作组需要平衡。
- 恶意举报防护条款是双刃剑——它保护被滥用举报的人，但也可能让真正受害的人担心"我会不会被判定为恶意举报"。执行手册里必须写清楚判断标准。
- 透明度和隐私有张力——公开处置统计是好事，但具体案例的细节涉及当事人隐私，披露边界需要提前定义。
- 小型项目可能没有工作组的人力——Covenant 3 的执行要求比旧版更高，如果你的项目只有两三个维护者，先确保有人能响应举报，再考虑采纳。
Django 能走完三步，靠的是有专门的工作组和 DSF Board 的支持。单人维护的项目，至少先把举报渠道和基本执行流程跑通，再逐步对齐 Covenant 3 的完整要求。
去哪里看
Django 的全套 CoC 文档已经上线：
- 行为准则：
djangoproject.com/conduct - 举报指南：
djangoproject.com/conduct/reporting - 执行手册：
djangoproject.com/conduct/enforcement-manual - FAQ：
djangoproject.com/conduct/faq - GitHub 仓库：
github.com/django/code-of-conduct
完整变更记录也在仓库里。如果你在维护自己的开源项目，值得逐条对比 Django 的增强条款和基础 Covenant 文本之间的差异——那些差异正是"从模板到可执行框架"的缝隙所在。