Django 的技术治理调整已经跨过关键节点：Steering Council 与 Django Software Foundation（DSF）董事会均批准了 DEP 19。它不是一次普通的文档修订，而是对技术决策机制的重新梳理——减少复杂度，让治理流程更容易理解，也让更多社区成员能够参与其中。
这项调整由两届不同的 DSF 董事会和数十位社区成员共同推动。接下来，维护者还需要同步更新 Django 与 djangoproject.com 仓库中的相关文档，完成后 DEP 才会进入最终状态并移动到对应目录。
批准完成，不等于迁移结束
DEP 19 已经获得两个治理机构批准，这意味着新治理方案具备了正式实施的基础。不过，从“决策通过”到“项目按新规则运作”，中间仍有一段容易被低估的迁移期。
至少需要处理三类一致性问题：
- 规范一致性：治理文档不能继续描述旧角色、旧资格要求或已经取消的流程。
- 入口一致性：官网、贡献指南、选举说明与仓库文档应指向同一套规则。
- 状态一致性：DEP 的状态、目录位置和引用方式需要反映它已经获批并落地。
如果只更新 DEP 本身，而遗漏贡献指南或网站页面，新贡献者仍可能按照旧流程行动。治理变更的完成标准，因此不应只是“提案合并”，还应包括所有公开入口的同步。
精简治理，真正减少的是参与门槛
这次调整的核心方向是简化与缩减。这里的“缩减”不应理解为减少必要的审查或责任，而是移除不必要的结构、重复描述和难以理解的资格壁垒。
开源项目的治理规则越复杂，参与者就越容易产生三种误判：
- 不知道应该由谁作出决定；
- 不确定自己是否有资格参与；
- 认为只有长期维护核心代码的人才能承担治理职责。
DEP 19 中尤其值得关注的是新的 Steering Council 资格标准。提案定义了一组范围更广、对委员会工作有帮助的素质，希望社区成员能够从中发现：自己可能已经具备参选条件。
来源摘要并未列出这些标准的完整条目，因此不宜把它们擅自简化成某种固定清单。更重要的变化是判断方式：候选人的价值不再只由单一类型的贡献来表达，而可以从多种能力和社区经验中体现。这有助于把“谁像传统核心开发者”转化为更实际的问题——“谁能帮助委员会作出可靠、透明且符合项目长期利益的技术决策”。
更宽的资格表达也不等于降低要求。Steering Council 仍然需要承担技术判断、沟通和责任，只是社区不必再用过于狭窄的经历模板筛选候选人。
可以这样审计两个仓库中的治理文档
下面是一个可复制改造的迁移示例。假设本地工作区中存在名为 django 和 djangoproject.com 的两个仓库；脚本只生成关键词清单，不会修改文件，也不代表 Django 项目的正式维护工具。
将以下内容保存为 audit-governance-docs.sh：
#!/usr/bin/env bash
set -euo pipefail
roots=("django" "djangoproject.com")
pattern='Steering Council|technical governance|governance|eligibility|election|DEP 19'
for root in "${roots[@]}"; do
if [[ ! -d "$root" ]]; then
printf '跳过：未找到目录 %s\n' "$root" >&2
continue
fi
output="governance-audit-${root//\//-}.txt"
printf '正在扫描 %s ...\n' "$root"
find "$root" \
-type d \( -name .git -o -name node_modules -o -name .venv \) -prune -o \
-type f \( \
-name '*.md' -o \
-name '*.rst' -o \
-name '*.txt' -o \
-name '*.html' \
\) -print0 \
| xargs -0 grep -Ein "$pattern" 2>/dev/null \
| sort > "$output" || true
printf '结果已写入 %s\n' "$output"
done
运行方式：
chmod +x audit-governance-docs.sh
./audit-governance-docs.sh
生成的清单可以用于逐项检查：
- 页面是否仍在引用旧治理结构；
- Steering Council 的资格说明是否需要替换；
- 选举与提名文档是否采用新术语；
- DEP 状态与所在目录是否一致；
- 两个仓库对同一角色的描述是否冲突。
团队还可以在仓库中维护一份临时迁移清单。以下 YAML 只是可改造的项目管理示例，并非 DEP 19 规定的文件格式：
change: dep-19-governance-rollout
status: in-progress
approval:
steering_council: approved
dsf_board: approved
repositories:
- name: django
checks:
governance_docs: pending
contribution_docs: pending
stale_references: pending
- name: djangoproject.com
checks:
governance_pages: pending
election_pages: pending
cross_links: pending
completion:
documentation_updated: false
dep_moved_to_final_state: false
这种清单的价值不在于格式，而在于把“提案已经通过”和“迁移已经完成”拆成两个可验证的状态。
落地时应守住的边界
技术治理简化之后，项目仍需要保留足够的可追溯性。实施 DEP 19 时，可以重点检查以下事项：
- 新旧文档之间不存在互相矛盾的资格描述；
- 社区成员能快速找到参选、提名和了解职责的入口；
- “更广泛的资格”没有被重新解释成隐性的单一路径；
- 重要技术决策仍能说明由谁负责、如何形成以及如何被记录；
- 文档更新完成后，再将 DEP 标记为最终状态并移动到相应目录。
DEP 19 最重要的成果，未必是少了多少规则，而是更多贡献者能够看懂治理体系，并合理判断自己是否适合参与。对于成熟开源项目而言，这种可接近性本身就是技术可持续性的一部分。