dotnet/runtime 自动化 Issue 清理机制两阶段 stale 标记到关闭的完整实现解析【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtimedotnet/runtime 是 .NET 运行时、类库与 Mono/CoreCLR 等子系统的统一仓库社区每天会提交数十个 Issue。为了不让积压backlog中大量三年以上无任何活动的旧 Issue 持续沉淀仓库团队实现了自动化清理机制先把 stale Issue 标记为清理候选并通知若 14 天内无任何新评论则自动关闭有任何评论则自动撤销流程。读完本文你将掌握该机制的完整运作流程、仓库内真实配置的逐项解读.github/policies/resourceManagement.yml以及这套模式在自有仓库中的落地要点。背景为什么 dotnet/runtime 需要自动化清理 backlogdotnet/runtime 是一个高流量的开源仓库社区每天都会提交大量 Issue。尽管维护者尽力快速响应与解决仍不可避免地有一部分 Issue 会在 backlog 中长期停滞。据 docs/issue-cleanup.md 记载仓库中曾存在数百个超过三年没有任何活动的 Issue。这些长期闲置的 Issue 会带来几个实际问题噪音与维护成本维护者筛选 backlog、定位真实待办时陈旧 Issue 会稀释注意力信息失真很多旧 Issue 所基于的版本早已迭代问题可能已修复或已过时社区体验贡献者面对大量僵尸 Issue难以判断哪些仍然有效、值得投入。自动化清理的目标是让 backlog 更精简、更聚焦要么促使维护者与社区重新评估旧 Issue重新排期或提升优先级要么将其作为已解决或已过时关闭。两阶段清理机制的核心流程这套自动化采用两阶段two-phase流程核心设计是先警告、后关闭给所有利益相关方留下充分的反应窗口第一阶段标记为清理候选当自动化发现满足条件的 stale Issue长期无活动且处于打开状态时会在 Issue 下追加一条通知评论打上backlog-cleanup-candidate标签将其标记为清理候选。反应窗口任何反馈都会撤销流程如果这条通知触发了任何反馈——例如有人不限于 Issue 作者本人回复了评论、补充了复现信息、维护者重新评估了优先级——流程会立即撤销the process is undone该 Issue 不再走向关闭。第二阶段14 天后自动关闭如果 14 天内没有任何进一步活动自动化会执行关闭操作。这一设计意图明确它不是为了无差别删除旧 Issue而是触发对旧 Issue 的重新评估——既面向维护者可以重新排期、重新优先级化也面向社区可以补充信息证明其仍然有效。最终结果只有两种被重新激活或被作为已解决/已过时关闭。源码级解读自动化在仓库中的真实配置这套机制并不是文档中的纸面设计而是由仓库根目录下的策略文件.github/policies/resourceManagement.yml真实承载的。该文件基于GitOps.PullRequestIssueManagement原语primitive核心由scheduledSearches定时搜索与eventResponderTasks事件响应两部分组成。1. 清理候选的识别规则- description: Automated Issue cleanup frequencies: - hourly: hour: 6 filters: - noActivitySince: days: 1644 - isIssue - isOpen - isNotLabeledWith: label: backlog-cleanup-candidate - isNotLabeledWith: label: area-codegen-coreclr - isNotLabeledWith: label: area-iltools-coreclr - isNotLabeledWith: label: area-tools-ilverification actions: - addReply: reply: - Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of our [issue cleanup automation](https://github.com/dotnet/runtime/blob/main/docs/issue-cleanup.md). - addLabel: label: backlog-cleanup-candidate - addLabel: label: no-recent-activity逐项解读这套过滤规则配置项取值含义frequencieshourly: hour: 6定时任务每小时运行一次在每小时的第 6 分钟触发扫描noActivitySince.days1644无任何活动超过 1644 天约 4.5 年的 Issue 才进入候选扫描范围isIssue—只处理 Issue不处理 Pull RequestisOpen—只处理仍处于打开状态的 IssueisNotLabeledWith: backlog-cleanup-candidate—已经打过该标签的 Issue 不重复处理isNotLabeledWith三个area-*标签area-codegen-coreclr、area-iltools-coreclr、area-tools-ilverification特定领域coreclr 代码生成、IL 工具、IL 验证的 Issue 被排除在自动清理之外排除列表的存在说明自动化清理并非一刀切涉及 JIT/代码生成等复杂领域的旧 Issue 往往仍具参考价值因此被显式豁免。这与 docs/project/issue-guide.md 中Issue 代表未来应做的可执行工作只要属于团队职责范围就保持打开的原则保持一致。而触发后执行的三个动作addReply 两个addLabel正是原文档描述的通知 标记回复模板明确说明由于缺少近期活动本 Issue 已被标记为 backlog 清理候选若 14 天内无进一步活动将被关闭任何新评论不限作者都会撤销此流程。2. 配套的no-recent-activity标签流同一个策略文件还定义了围绕no-recent-activity标签的完整生命周期它服务于另一类场景——等待作者回应的 Issue/PR打标签对带needs-author-action标签、14 天无活动的打开 Issue以及 PR自动加上no-recent-activity标签并追加说明评论关闭对已带no-recent-activity标签、又过了 14 天仍无活动的 Issue/PR追加评论后执行closeIssue关闭关闭后的提醒关闭评论会提示——Issue 仍可重新打开或评论但若再保持 30 天无活动将被锁定lock。由此可见仓库实际运行着两套并行的时间轴一套是面向三年以上老 Issue的backlog-cleanup-candidate流程另一套是面向等待作者动作的no-recent-activity流程。两者共享14 天无活动即关闭的窗口期设计前者窗口更宽松、仅针对超长期闲置后者则约束需要作者回应的新近 Issue。3. Draft PR 的自动关闭策略文件还覆盖了长期搁置的草稿 PR- description: Close inactive Draft PRs filters: - isDraftPullRequest - isOpen - noActivitySince: days: 30 actions: - closeIssue - addReply: Draft Pull Request was automatically closed for 30 days of inactivity.30 天无活动的 Draft PR 会被自动关闭关闭评论会引导作者联系 docs/area-owners.md 中的负责人申请重新打开。这与 docs/project/issue-guide.md 中保持只有活跃 PRWIP PR 不应变得 stale超过 2 周若 PR stale 且没有立即推进路径考虑关闭直到解除阻塞的维护原则相互印证。4. 事件响应按 area 标签自动通知负责人除了定时扫描同一文件中的eventResponderTasks还实现了事件驱动的联动当 Issue 或 PR 被打上某个area-*标签如area-System.Text.Json、area-GC-coreclr、area-System.Net.Http等上百个领域标签时自动通过mentionUsers在评论中 对应领域的维护者或团队如dotnet/gc、dotnet/jit-contrib并附上 docs/area-owners.md 的订阅指引。这保证了打标签 → 领域负责人收到通知的链路自动化是 issue 治理中与清理机制互补的另一半。清理链条的收尾locker 工作流被自动关闭的 Issue 并非流程终点。仓库通过.github/workflows/locker.yml实现锁定期治理该工作流每天定时cron37 8 * * *运行默认对关闭后 30 天且更新后 30 天无活动的 Issue/PR 执行锁定lock且支持workflow_dispatch手动触发并传入自定义天数。同时它监听reopened事件若关闭的 Issue/PR 被重新打开但处于锁定状态会自动执行解锁unlock确保重新激活的讨论不被锁死。至此形成完整闭环打开 Issue →超 1644 天无活动→ 打 backlog-cleanup-candidate 标签 通知 → 14 天内有人评论→ 是撤销流程继续保留 → 否自动关闭 →关闭后 30 天无活动→ 锁定而needs-author-action场景则走no-recent-activity14 天打标签 14 天关闭的更短周期两者共同构成仓库的自动清理体系。对社区贡献者与维护者的实践启示无论你是 dotnet/runtime 的 Issue 提交者、贡献者还是其他开源仓库的维护者这套机制都提供了可复用的经验对 Issue 作者收到backlog-cleanup-candidate通知意味着你的 Issue 即将进入关闭倒计时。任何新评论不限作者本人都会撤销流程——补充复现步骤、更新当前版本下的行为、或说明为何仍需要该功能都是有效的续命方式如果问题已解决也可以借此机会主动关闭并注明原因。对维护者清理自动化是触发重新评估的机制而非删除工具。通过 docs/project/issue-guide.md 中每个 Issue 恰好一个area-*标签、无 Assignee 除非正在处理、尽量用help wanted、不害怕拒绝但要礼貌解释的 triage 规则配合本机制即可让 backlog 长期保持聚焦。对自有仓库resourceManagement.yml中scheduledSearches的noActivitySince天数、isNotLabeledWith豁免标签列表、frequencies扫描频率和actions回复文案 标签都是可参数化的任何基于 GitHub 的仓库都可以按需裁剪这套两阶段 stale 清理模式。关键设计要点是先通知、给窗口、可撤销、再关闭——这比直接关闭旧 Issue 更尊重社区也更有数据依据。小结dotnet/runtime 的自动化 Issue 清理是一套精心设计的软关闭机制以backlog-cleanup-candidate标签和通知评论为第一阶段的警示以 14 天活动窗口为缓冲以自动关闭和后续锁定为收尾。它的真实配置位于.github/policies/resourceManagement.yml配套的.github/workflows/locker.yml与 docs/project/issue-guide.md 共同构成了仓库完整的 Issue 治理闭环。理解这套机制既能帮助你在参与 .NET 开源社区时正确应对清理候选通知也能为自有仓库设计自动化 backlog 治理提供可直接借鉴的范式。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考