4.8 KiB

Raw Blame History

Maintainer Playbooks

Playbook 是把 Evidence Pack 转成治理动作的规则库。Agent 应选择 1-3 个最相关剧本。

P1 低活跃恢复

触发条件：

[E9] 最近 30 天提交很少或没有提交。
[E2] open Issue 有新增但缺少回复。
[E10] 贡献者集中在 1-2 人。

风险信号：

项目对外仍有关注、Fork 或 Issue，但维护节奏下降。
新贡献者不知道项目是否还接受贡献。

本周动作：

回复所有超过 14 天未更新的 open Issue。
创建“维护状态说明”Issue，说明当前优先级和可接受贡献范围。
标记 2-3 个适合外部贡献者的小任务。

30/60/90 天计划：

30 天：清理过期 Issue，保留可复现、可行动的问题。
60 天：补 README 的安装、运行、贡献入口。
90 天：建立每月一次的维护节奏，发布一个小版本或维护公告。

验收标准：

open Issue 中超过 14 天未回复的数量减少 70%。
至少 3 个 Issue 有明确下一步。
README 有贡献入口或维护状态说明。

P2 PR 堵塞清理

触发条件：

[E4] open PR 数量较多。
[E4] 存在超过 7 天未更新或未评审的 PR。
[E5] merged PR 样本少于 open PR 样本。

风险信号：

贡献者提交后长期没有反馈。
PR 无法合并导致贡献热情下降。

本周动作：

按“可合并 / 需要修改 / 已过期”三类整理 open PR。
对每个超过 7 天未更新的 PR 留下明确反馈。
优先合并低风险文档、测试、修复类 PR。

30/60/90 天计划：

30 天：把 open PR 降到可管理数量。
60 天：建立 PR 模板和评审 SLA。
90 天：把常见检查迁移到 CI，减少人工评审负担。

验收标准：

所有 open PR 都有最新维护者反馈。
超过 14 天未更新的 open PR 数量降到 0 或给出关闭理由。
新 PR 平均首次响应时间少于 7 天。

P3 新人友好改造

触发条件：

[E12] README 缺少安装、运行、测试、贡献指南中的任意两项。
[E2] open Issue 缺少标签或优先级。
[E10] 贡献者数量少，但项目仍有 Issue 或关注。

风险信号：

潜在贡献者无法判断从哪里开始。
Issue 内容对新人不可执行。

本周动作：

在 README 补充最短运行路径。
给 2-5 个简单 Issue 加上“good first issue”或等价说明。
为新人任务补充复现步骤、预期行为和验收标准。

30/60/90 天计划：

30 天：补齐 README、CONTRIBUTING 或 Issue 模板。
60 天：形成新人任务池。
90 天：复盘新人贡献转化，保留有效标签和模板。

验收标准：

README 包含安装、运行、测试、贡献四个入口。
至少 3 个 Issue 可被新人独立领取。
新 Issue 模板能引导用户提供复现信息。

P4 Release 稳定化

触发条件：

[E7] 没有 Release，或最近 Release 距今较久。
[E9] 最近提交包含多项功能或修复。
[E5] 已合并 PR 有明显用户可见变更。

风险信号：

用户无法判断可用版本。
变更沉淀在提交记录中，没有形成版本说明。

本周动作：

生成下一版 Release Notes 草稿。
梳理已合并变更为 Added / Fixed / Changed / Docs。
明确是否需要补充测试或 CI 后再发布。

30/60/90 天计划：

30 天：发布一个维护版本或明确下个版本计划。
60 天：固定 Release Notes 模板。
90 天：把 Release 与里程碑、Issue、PR 建立关联。

验收标准：

至少有一个可追溯 Release 或版本计划。
Release Notes 能关联主要 Issue/PR/Commit。
用户能从 README 找到最新稳定版本。

P5 基础治理补齐

触发条件：

[E1] license_name 为空。
[E1] description 为空或项目元信息不足。
[E8] CI 数据缺失或持续失败。
[E12] README 缺失或内容过短。

风险信号：

项目难以被搜索、复用、评审或贡献。
比赛/开源收录时材料不完整。

本周动作：

补项目描述、License、README 快速开始。
确认默认分支和基础 CI 状态。
建立一个“项目治理基线”Issue 追踪补齐事项。

30/60/90 天计划：

30 天：补齐 README、License、基础元信息。
60 天：补 Issue/PR 模板和贡献说明。
90 天：形成版本发布、CI、维护响应的固定节奏。

验收标准：

仓库详情中项目描述、License、README 均可见。
CI 至少覆盖构建或测试中的一项。
维护者能用一个治理 Issue 跟踪剩余事项。

选择规则

High 风险剧本优先。
同类风险只选择一个主剧本，避免输出重复建议。
如果数据样本少，优先选择 P5 基础治理补齐。
如果用户明确关注新人、Release 或 PR，则用户目标优先于自动排序。