Stale Bot 的温和配置:保持活跃度同时清理休眠反馈
Stale Bot 的温和配置:保持活跃度同时清理休眠反馈

在开源社区治理中,Stale Bot(休眠 Issue 自动清理机器人)是一个极具争议的存在。
配置不当的 Stale Bot 常常会激怒社区贡献者:用户认认真真提了一个包含完整复现堆栈的重大 Bug,维护者因为忙碌三周没有回复,机器人突然跳出来留下一句冰冷的“由于长时间没有活动,此 Issue 即将被关闭”,并在 7 天后无情锁帖。这种行为被社区广泛批评为“维护者为了粉饰 Issue 解决率数据而推卸责任”。
然而,如果完全不引入自动化清理机制,开源仓库中又会堆积大量提问者早已不再关心、或者经过几个版本迭代后早已无法复现的“僵尸 Issue”,严重稀释维护者的日常精力。
一个成熟、有温度的开源项目,必须对 Stale Bot 进行极其温和、精准的分层配置:只清理“缺乏必要信息的未响应反馈”,绝对不误伤“真实存在但尚未排期修复的已知缺陷”。
区分 Stale 的核心原则:看责任方在谁
判断一个 Issue 是否应该进入 Stale 清理生命周期,唯一的核心标准是:当前的阻塞球在提问者(Reporter)手里,还是在维护者(Maintainer)手里?
graph TD
A[新 Issue 提交] --> B{是否缺少环境/复现步骤?}
B -->|是| C[打上 need-more-info 标签: 球在提问者手里]
C -->|提问者 14 天未补充任何信息| D[触发 Stale 提醒 -> 7 天后温和关闭]
C -->|提问者补充了信息| E[自动移除 need-more-info: 球回到维护者手里]
B -->|否: 信息完整已确认| F[打上 bug / confirmed / help-wanted 标签: 责任在维护者]
F --> G[永久加入 exempt-issue-labels 豁免名单 严禁机器人打扰!]
GitHub Actions Actions-Stale 温和配置实战
我们使用 GitHub 官方推荐的 actions/stale,在 .github/workflows/stale-governance.yml 中实现分级治理:
name: Gentle Issue Governance
on:
schedule:
- cron: '0 4 * * *' # 每日凌晨低峰期执行一次
jobs:
stale:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v9
with:
# 仅针对打上了 need-more-info 或 waiting-for-user 的 Issue 计时
only-issue-labels: 'need-more-info,waiting-for-user'
# 宽容的时间窗口:14 天无响应标记 Stale,再过 7 天关闭
days-before-issue-stale: 14
days-before-issue-close: 7
# 豁免所有已确认的 Bug、重大功能提议与 PR
exempt-issue-labels: 'confirmed,kind/bug,help-wanted,pinned,security,rfc'
exempt-all-issue-milestones: true
exempt-all-issue-assignees: true
# 绝对不清理 Pull Request(PR 是贡献者的劳动成果,必须人工评审)
days-before-pr-stale: -1
days-before-pr-close: -1
# 温和、具有建设性的提示文案
stale-issue-message: >
👋 您好!由于该 Issue 标记了 `need-more-info` 且过去两周内未收到补充信息,系统已将其标记为待休眠状态。
如果您依然遇到此问题,**只需在此回复补充最新的复现日志或最小 Demo**,系统将自动恢复活跃状态;若问题已解决,也欢迎随时告知我们。感谢对社区的支持!
close-issue-message: >
该 Issue 因长期缺乏复现详情已自动关闭。若未来有新的复现线索,随时欢迎重新开启或提交新的反馈。祝编码愉快!
stale-issue-label: 'status/stale'
三大关键温和设计细节
1. 提问者一旦回复,秒级自动解除 Stale
通过配套一个轻量级的 Webhook 监听事件,当作者在被标记为 stale 的 Issue 中发表新评论时,GitHub Actions 立即移除 status/stale 和 need-more-info 标签,并将其重新推到维护者的待办队列顶部。
2. 严禁对 Pull Request 启用自动化 Stale 关闭
贡献者花费心血编写的代码 PR,即使因为架构原因暂时无法合并,也必须由人类维护者亲自在评论区给出详尽的 Review 意见并手动处理,绝不能由机器人冷漠地 Stale 关闭。
3. 给贡献者留下随时 Reopen 的尊严
在关闭消息中必须明确说明:“关闭只是为了看板归档,随时欢迎提问者在有空补充日志时自行 Reopen”。
治理成效
在推行这套温和治理规则后:
- 仓库中长期悬而未决的“无日志无效反馈”自然下降了 75%,Issue 列表保持高度清爽;
- 社区对于机器人的抱怨与抵触归零,提问者收到提示后的有效日志补全率反而提升了 40%。
开源治理的本质是对人的连接与共建。用温和的规则过滤噪音,把最真诚的精力留给每一次有价值的技术交流,才是让开源项目长盛不衰的根本之道。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐



所有评论(0)