深入解读 ASP.NET Core 仓库的 Issue 分诊机制（Triage Process）：分类规则、里程碑规划与自动化落地

深入解读 ASP.NET Core 仓库的 Issue 分诊机制（Triage Process）：分类规则、里程碑规划与自动化落地

【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore

本文基于 docs/TriageProcess.md 整理并展开。ASP.NET Core 是微软旗下跨平台的高人气 Web 框架仓库，Issue 流量常年巨大，如何在“持续创造新功能”与“处理大量既有问题的调查与修复”之间取得平衡，是一支小团队面临的真实挑战。本篇将完整梳理该仓库的 Issue 分诊流程——从问题分类、标签体系、里程碑规划到发布规划与清理机制，并结合仓库内真实存在的自动化策略文件、Issue 模板与说明文档，呈现一套可借鉴、可落地、可自动化的开源项目社区治理方案。读完本文，你将能理解 ASP.NET Core 官方团队如何处理高流量 GitHub 仓库的反馈，并可将这套规则迁移到自己的开源项目中。

背景：为什么大型仓库需要一套分诊规则

维护一个人气 GitHub 仓库绝非易事。过去几年，ASP.NET Core 仓库收到的 Issue 数量持续增长——这既是框架与生态系统健康发展的信号，也让团队难以逐一及时响应。为了跟上不断变化的社区预期，官方团队引入了一组规则，用于更好地处理后续涌入的 Issue。

这套规则围绕以下三个目标设计（按优先级排序）：

1. 让每个 Issue 的分诊决策变得容易——团队能快速判断每个 Issue 的性质；
2. 能够轻松地为每个里程碑排定优先级——哪些事先进、哪些事后进一目了然；
3. 让客户对 Issue 的处理方式建立合理预期——明确告诉用户问题会被如何对待。

注意：需要紧急调查帮助的客户应联系 Microsoft Support（微软官方支持渠道），而不是通过 GitHub Issue 提出。

分诊流程详解：先分类，再处理

分诊的核心思想很简单：各功能团队应当能够逐条浏览针对该仓库提交的每一个 Issue，并快速就其性质做出判断。因此，团队会先将 Issue 分类，再根据类别采取对应处理规则。分类的依据主要来自 Issue 描述、堆栈、涉及文件路径与 API 名称等信息。

以下小节分别对应分诊会议中使用的几大类别及其处理规则。

信息收集（Information Gathering）：Needs: Author Feedback

当问题信息不足以推进调查时，团队进入“信息收集”阶段：指导用户收集合适的诊断信息，看其是否能借助这些额外信息自行解决问题。

• 当需要用户输入时，会为该 Issue 打上Needs: Author Feedback标签；
• 团队会尽量快速（几天内）响应此类 Issue；
• 处于该阶段的 Issue 可能因长期未收到及时回复而被自动关闭——它们往往没有提供足够信息供团队继续深挖；
• 如果用户已收集齐全相关诊断信息而问题依然不明确，则该 Issue 会被纳入后续的调查（Investigations）流程由团队处理。

这一阶段在仓库中已有非常完整的自动化实现，可参见 .github/policies/resourceManagement.yml：

• 定时搜索（每周一至周五）会找出带有Needs: Author Feedback且已打上Status: No Recent Activity、超过 3 天无活动的开放 Issue 并直接closeIssue；
• 当Needs: Author Feedback已存在 4 天且无活动时，自动添加Status: No Recent Activity标签并留言提醒：若在评论后 3 天内仍无活动将被关闭，若日后能提供补充信息，欢迎随时重新打开并重新调查；
• 当 Issue 作者重新评论时，事件响应任务会自动把Needs: Author Feedback替换为Needs: Attention标签。

配套的政策说明见 docs/IssueManagementPolicies.md：作者若在7 天内未回应，Issue 会被自动关闭；若在关闭后7 天内回应，则会被自动重新打开。团队也明确表示：理解用户未必能立即回复，任何时候能提供新信息都欢迎。

功能请求（Feature requests）：enhancement标签

一旦确认某个 Issue 是“新功能请求”，团队会为它打上enhancement标签，并通常将其自动移入.NET 11 Planning里程碑，留待后续 Sprint 规划会议进一步评审。

• 如果认为该功能请求与项目目标不符，团队可能选择立即关闭；
• 某些情况下团队希望先收集更多反馈再行动，此时会将 Issue 移入Backlog里程碑，留待发布规划阶段评审。

仓库提供了专门的功能请求模板 .github/ISSUE_TEMPLATE/20_feature_request.yml，模板内要求填写：是否已搜索既有 Issue、该功能请求是否关联到某个实际问题（"I am trying to do [...] but [...]"）、期望的解决方案与备选方案、以及额外上下文。

Bug 报告（Bug reports）：bug标签

如果能够立即确定 Issue 与框架中的 Bug 相关，团队会打上bug标签，然后尝试评估其影响与严重程度，并据此决定去向：

• 严重（critical）：可能纳入当前里程碑立即处理，甚至考虑紧急补丁（servicing patch）；
• 影响相对较大：移入.NET 11 Planning里程碑，留待 Sprint 规划会议评审；
• 影响不明确或属极端边界场景：移入Backlog里程碑，稍后通过观察客户 upvotes / 评论数再评估影响。

仓库的 Bug 报告模板见 .github/ISSUE_TEMPLATE/10_bug_report.yml，其结构本身就服务于分诊决策：包含是否已搜索既有 Issue、Bug 描述、期望行为、最小化复现项目（要求公开 GitHub 仓库、拒绝.zip附件与复杂自定义项目、拒绝私有仓库）、异常信息、.NET版本（dotnet --version）与额外上下文（含dotnet --info输出）。

调查（Investigations）：investigate标签

很多场景下，一个 Issue 是否是 Bug 并不能立刻判定，团队需要先花时间调查才能决定其去向。此时会打上investigate标签。

• 经验上，这类 Issue 多数最终被证实是用户代码中的某种配置错误；
• 但极少数情况下它们背后是影响巨大的严重问题。因此团队会在分诊时决定：是否有必要立即调查某些 Issue；
• 若无需立即调查，调查任务会被移入.NET 11 Planning里程碑，留待接下来的 Sprint 规划会议评审。

文档请求（Documentation requests）：Docs标签

有些 Issue 实际反映的是用户对框架某方面配置方式的困惑。判定后团队会为其打上Docs标签，并移入.NET 11 Planning里程碑稍后处理。其目标是通过补齐或澄清文档，让客户能依据官方文档中的指引成功使用框架。

• 若某类文档问题有太多客户都遇到麻烦，团队也可能选择在当前里程碑内优先解决。

里程碑规划（Milestone Planning）

团队的里程碑通常以一个月为周期。每个里程碑开始前会召开一次或多次规划会议，遍历.NET 11 Planning里程碑中积累的全部 Issue，从中挑选最重要、影响最大的若干项，纳入下一个里程碑处理。入选内容通常是功能请求、Bug 修复、文档问题以及部分调查任务的混合体。

值得注意的筛选原则：

• 团队只会调查积累了超过一定数量 upvotes 和/或评论的 Issue——这说明其影响面较大；
• 没有获得多少投票/评论的 Issue 可能不会被调查而直接关闭，理由是影响面非常有限，且问题可能出在用户代码中。官方建议这类问题可以到 StackOverflow 上提问；
• 对于部分功能请求和 Bug 报告，视用户参与度而定，可能会在此时移入 backlog——这意味着在下一次大版本发布规划之前，它们将不再被查看。

这一“月度、按优先级挑选”的运作节奏说明：即便仓库有自动化兜底，真正的人力投入仍集中于高影响、高社区呼声的问题。

发布规划（Release Planning）

当发布周期接近尾声（例如 .NET 10 收官）时，团队会审视Backlog里程碑中积累的 Issue。由于该里程碑中积累的 Issue 数量庞大，这是一个漫长的过程。

• 团队会优先处理与项目目标一致且社区请求/upvotes 最多的 Issue；
• 被认为是下个版本候选的 Issue，会被移入.NET 11 Planning里程碑。

完整的发布规划方法见 docs/ReleasePlanning.md。该文档描述了为下一个大版本筛选候选 Issue 的五阶段流程：

1. 过滤与个人优先级排序（Filtering & Individual prioritization）：所有 Issue 按功能领域分发给工程师，每位工程师为其领域内的每个 Issue 打上个人优先级标签fl-p1/fl-p2/fl-p3（fl为工程师姓名首字母）。低于Priority-3的留在 backlog；工程师带回的 Issue 上三种优先级标签的分布大致均衡，以强制进行真正的优先级排序。合格候选移入.NET V Planning里程碑（V 为下一版本号）；
2. 粗略成本估算（Rough costing）：工程师为移入规划里程碑的 Issue 施加Cost: X成本标签，用于后续规划。对于描述不清晰的工作，需在评论中总结相关工作，便于日后答复成本疑问，同时要注意重新评估那些过时或不再准确的旧成本标签；
3. 团队评审与优先级调整（Team Review & Priority adjustment）：团队从最高优先级开始逐条评审并达成一致，随后为每个 Issue 打上Priority: X标签。每个Priority: 1的 Issue 被移入项目看板（从Triage列起步），用于全年跟踪发布工作；
4. 容量规划（Capacity planning）：通常只为该工作预留团队 50% 的产能——因为全年会不断涌入新的用户反馈，需要留出时间处理；
5. 划定截止线（Define the cut line）：对候选 Issue 进行栈式排序（stack ranking），使最重要的工作保持在列表顶部，然后画出截止线，从而大致确定团队在下个发布周期要处理的工作清单。

清理（Cleanup）：超过 2 个发布周期未处理的低优先级 Issue

在发布规划过程中遍历Backlog里程碑的全部 Issue 时，团队会同步清理里程碑：关闭那些已在 backlog 中滞留**超过 2 个发布周期（release）**的低优先级 Issue。

理由很务实：虽然其中某些 Issue 看起来似乎合理，但它们在如此长的时间内都未被解决，恰恰说明其对产品的重要性并不像表面看起来那么大。

配套地，仓库的自动化策略 .github/policies/resourceManagement.yml 中也体现了一整套“无活动即清理”的闭环：处于Discussions里程碑、60 天无活动且未标记announcement的 Issue 会被自动关闭（并提示 30 天后将被锁定）；带有Status: Resolved标签且 1 天无活动的 Issue 会被自动关闭。

流程总览图

下面这张图概括了上文描述的全部分诊流程（图片为原文档所附的流程可视化图，托管于外链图床，读者可结合文字描述理解整体流转）：

支撑这套流程的自动化与配套资料

原文档在 References 一节中指出：团队依赖一些自动化来支撑上述流程。在本仓库中，这些自动化与配套资料确实真实存在，值得读者按图索骥深入阅读。

问题管理策略：docs/IssueManagementPolicies.md

该文档是本分诊流程的重要配套，规定了仓库对 Issue 的通用管理策略，包括：

• 不要在已关闭的 Issue 上继续评论：关闭的 Issue 不会出现在分诊流程中，建议开新 Issue 并链接到旧 Issue；同时官方明确不介意重复 Issue——关闭重复 Issue 比在单个 Issue 上讨论多个根因更容易；
• Needs: Author Feedback：作者 7 天未回应自动关闭、关闭后 7 天内回应自动重开；
• PR 场景的pr: pending author input：要求作者 14 天内回应或更新 PR，否则自动关闭；关闭后 7 天内回应会自动重开；
• 重复 Issue：标记Resolution: Duplicate后，1 天无活动自动关闭；
• 已回答问题：标记Resolution: Answered后，1 天无活动自动关闭；
• 锁定已关闭 Issue：关闭后 30 天无活动即自动锁定为 resolved，以减少“到哪里发新评论”的困惑。

这些策略在 .github/policies/resourceManagement.yml 中均有对应的定时搜索与事件响应配置（例如标签Resolution: Answered/By Design/Duplicate/Won't Fix被添加时会自动追加Status: Resolved；带pr: pending author input的 PR 超过 10 天会被提醒stale，再超 4 天自动关闭，作者重新活动后自动重开）。

面向社区的入门索引：docs/README.md

该文档是本仓库所有贡献者文档的索引表，其中与本主题直接相关的条目包括“Issue management（问题管理策略）”与“Triage process（分诊流程）”，可帮助读者快速定位全套社区治理文档。仓库根目录还提供了本地构建说明 docs/BuildFromSource.md，供想从源码搭建本仓库的新贡献者参考。

可参考的其它治理类文档

• docs/Servicing.md：说明如何向既往发布分支提交补丁（含 “Shiproom Template”），对应自动化策略中针对release/8.0、release/9.0、release/10.0分支 PR 自动分配里程碑与servicing-consider标签的行为；
• docs/PreparingPatchUpdates.md：介绍如何为 ASP.NET Core 准备补丁发布；
• docs/ReleasePlanning.md：上文已详细展开的大版本候选筛选流程；
• .github/workflows/locker.yml 与 .github/policies/resourceManagement.yml：分别承载“自动锁定沉寂 Issue/PR”与“定时清理 + 事件响应”的自动化逻辑。

总结：一条从“人肉分诊”到“自动化治理”的完整路径

回顾整个 ASP.NET Core Issue 分诊体系，可以提炼出它对任何高流量开源仓库都通用的治理方法论：

1. 明确目标与预期：分诊规则先定义目标（易决策、易排期、预期清晰），再定义行为，让贡献者与用户都知道“接下来会发生什么”；
2. 先分类、再处理：用一套稳定的类别（信息收集、功能请求、Bug、调查、文档请求）与标签体系（enhancement、bug、investigate、Docs、Needs: Author Feedback等）让任何工程师都能快速对 Issue 做出决策；
3. 双里程碑机制：.NET 11 Planning（近期的月度规划池）与Backlog（长期待评估池）相互配合，配合月度 Sprint 规划与年度发布规划完成两次“漏斗式”筛选；
4. 尊重社区信号：以 upvotes / 评论数作为影响面的量化依据，把有限人力投向高影响问题；
5. 自动化兜底 + 定期人工清理：借助 policy bot 自动打标签、留言、关闭沉寂 Issue、锁定陈旧讨论（见 .github/policies/resourceManagement.yml），把团队从机械劳动中解放出来，让人工精力集中在真正的技术决策上。

对于正在运营自己开源项目的开发者而言，可以直接把本文梳理的标签体系、回复时限、双里程碑与清理策略作为模板落地——这正是 ASP.NET Core 这样的大规模项目经过多年实践沉淀下来的工程化社区治理经验。

【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore