dotnet/runtime Issue 与 Pull Request 治理实践标签规范、Triage 流程、里程碑与自动化运维指南【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtimedotnet/runtime 是 .NET 的跨平台运行时仓库覆盖 CoreCLR、Mono、NativeAOT、底层库等社区与多个工程团队在同一仓库中协同工作。本篇技术指南系统梳理该仓库官方发布的 Issue 与 PR 管理规范从area-*标签体系、untriaged/needs further triage状态机到里程碑milestone策略、分支政策与自动化工具体系。读完本文你既能以贡献者身份理解如何让一个 Issue/PR 被正确分流与响应也能以仓库维护者身份掌握如何用标签、里程碑与机器人自动化保持大型仓库健康运转。一、核心理念与原则大型公共仓库的协作根基dotnet/runtime 的 Issues 与 Pull Requests 是跨团队、跨社区的共享资源。官方文档将其治理目标凝练为四条原则保持一个社区/一个团队的整体感不要让多个子团队各自为政导致贡献者无所适从用自动化给进站/在途的 Issue 与 PR 打标签从而实现问责制accountability每个条目都要有人负责area-*标签应与某个具体的社区/团队对应标签即职责契约在同一个area-*内部允许各团队保留适合自己的局部实践全局统一规范 局部灵活度并存。这套原则的落地产物就是下文通用策略中的一整套标签状态机与机器人自动化。需要强调的是原则与规范是人的约定而真正的高效运转依赖仓库中实际的自动化配置文件见第六节二者共同构成了 dotnet/runtime 的 Issue/PR 治理闭环。二、通用策略标签、Triage 与锁定的核心规则以下是 dotnet/runtime 全员必须遵守的公共策略也是理解整个治理体系的关键规则说明自动打area-*标签所有新提交的 Issue 与 PR 都会被自动标记一个area-*标签机器人同时会给新建的 Issue不含 PR打上untriaged标签恰好 1 个area-*标签每个 Issue / PR 应且只应有1 个area-*标签避免多团队归属不清Triage 完成标志当untriaged标签被移除该 Issue 即视为已 triageneeds further triage标签用于标记需要以后再仔细看一次的条目换区必须重新 Triage当area-*标签被切换时必须重新添加untriaged标签防止 Issue 在并未真正被新区域负责人 triage 的情况下误入已 triage状态未来可能由机器人自动强制这一行为中央仓库所有者兜底当自动化无法判断归属区域时无法获得area-*标签的 Issue 与 PR 由中央仓库所有者负责 triage 与分发融合技术标签命名凡涉及多个合并技术的area-*标签需追加对应src/子目录名。例如area-Infrastructure之外还有area-Infrastructure-libraries、area-Infrastructure-coreclr、area-Infrastructure-installer标签与里程碑共享所有area-*标签、所有里程碑都是全仓库共享的新增/修改时需考虑整个 dotnet/runtime 的生态做负责任的公民关闭后 30 天锁定已关闭的 Issue 与 PR 在30 天无活动后被锁定lock。原因很简单关闭条目上的新评论极易被遗漏官方鼓励用户新建 Issue而不是在已关闭条目上继续讨论关于30 天锁定仓库中的实际自动化工作流给出了精确实现.github/workflows/locker.yml每天定时运行cron37 8 * * *以daysSinceClose: 30与daysSinceUpdate: 30为默认参数锁定过期条目同时监听reopened事件一旦 Issue/PR 被重新打开且处于锁定状态会自动执行解锁保证关闭-锁定不会阻碍新讨论的启动。三、需要 Area Owner 亲自出手的场景自动化只能完成分流与标记真正的 triage 决策必须由人完成。官方文档明确了两个强制管理场景untriaged标签的 Issue所有带untriaged标签的 Issue 都被视为未 triage。接近产品发布时各团队会被要求完成 triage若想留待日后细看可改用needs further triage标签。发布收尾release endgame与 servicing 期间针对特定版本的 Issue 与 PR 会被要求设置里程碑milestone以便按版本追踪与燃尽burndown。四、FAQ 详解从 Triage 定义到分支/镜像/看板政策官方 FAQ 是理解各项具体政策的最佳入口以下逐条展开并补充仓库证据。4.1 什么才算已 triage的 Issue默认情况下所有新提交的 Issue 都会被打上untriaged标签该标签存在即意味着需要 Area Owner 采取行动。在发布周期的特定时点Area Owner 可能被要求集中完成 triage。Triage 的最简形式就是移除untriaged标签但对大多数团队而言triage 意味着为 Issue 分配一个打算解决的里程碑。所有新条目还必须获得area-*标签——任何未获得area-*标签的 Issue 同样被视为未 triage。最佳实践当 Issue 从一个区域转移到另一个区域时应重新添加untriaged标签以提示新区域负责人需要在新的上下文中重新评估。4.2 里程碑Milestone如何处理里程碑标记是release endgame 与 servicing 期间的必要动作当发布进入 Issue 燃尽burndown阶段仓库所有者会要求 Area Owner 标记出应考虑纳入当前版本的 Issue。Servicing 的 PR应先添加major.minor.x形式的里程碑如3.0.x一旦确定具体 servicing 版本号再为 PR 补充精确里程碑如3.0.2。不设里程碑的 Issue 通常也是可接受的是否要求由各 Area Owner 自行决定没有里程碑 ≠ 未 triage。命名规范优先使用 3 段式里程碑名如3.0.0而非3.0以与其他仓库保持一致并便于报表统计。4.3 只有一个area-*标签时如何请求多个团队审查历史上给 Issue/PR 打多个area-*标签是为了吸引多个团队的注意。但为保障问责制现在每个条目只保留 1 个area-*标签若确实需要多团队关注请通过 Review 请求添加审阅人的方式而不是添加对方的area-*标签。4.4 dotnet/runtime 的通知机制是怎样的跟踪与关注 Issue 变化使用GitHub 默认通知系统。此外还有一个机器人当area-*标签被应用时发送通知。但它不会自动通知 Area Owner——因为并非所有人都想要这类通知。想接收区域通知的贡献者请按 docs/area-owners.md 中的说明自行订阅不需要具备 committer 权限。值得说明的是从仓库现状看docs/area-owners.md 已经扩展为一份完整的区域负责人名录覆盖 100 个area-*如area-System.Text.Json、area-GC-coreclr、area-NativeAOT-coreclr、os-*如os-android、os-wasi、arch-*如arch-loongarch64、arch-riscv标签的 Lead 与 Owners并额外列出了一批社区 Triage 成员Community Triagers——他们虽不隶属于具体区域但拥有协助路由和标记 Issue/PR 的权限。该文件明确指出编辑它并不会更新dotnet-policy-service用于区域通知的映射真正的映射在 .github/policies/resourceManagement.yml 中多数区域使用 GitHub Team 接收通知社区成员若想订阅可提交 PR 更新该配置文件参见 docs/infra/automation.md。4.5 PR 如何被打上标签与里程碑鉴于 dotnet/runtime 的规模所有 PR 都会被自动分配area-*标签此外部分 PR 会依据 release endgame 与 servicing 要求被附加里程碑。4.6 仓库的日常持续管理由谁负责仓库设有一位团队经理M2可能轮值对下列全局健康活动负责对无法自动分流的新条目进行 triage 并补打area-*标签公共基础设施common infrastructure的跟踪服务级别协议SLA跟踪——确保响应性与仓库健康发布 Issue 燃尽release issue burn down。而各个 Area Owner 则在其负责区域内按自己团队的方式管理各自的 PR 与 Issue。4.7 还有哪些其他 Issue 自动化可用官方文档描述了一套作者反馈自动流程当 Issue 因缺少作者提供的信息而无法推进时可打上needs author feedback标签若此后14 天内作者没有新评论机器人会添加no recent activity标签并附一条说明再过7 天仍无作者评论机器人会关闭该 Issue 或 PR期间任何人的评论都会清除no recent activity若评论来自作者本人则needs author feedback也会被清除并补上needs further triage以便团队重新看到它。从当前仓库的自动化配置看这套流程已在 .github/policies/resourceManagement.yml 中以GitOps.PullRequestIssueManagement的scheduledSearches方式落地实际使用的标签名为needs-author-action与no-recent-activity时间窗为14 天标记 再 14 天关闭——以配置文件为准它比文档描述的时间窗更长、更保守。该配置还实现了Draft PR 自动清理打开超过 30 天无活动的 Draft PR 会被自动关闭。此外仓库还有backlog-cleanup-candidate标签驱动的陈旧 Issue 清理流程详见 docs/issue-cleanup.md对超过约 4.5 年noActivitySince: days: 1644无活动的开放 Issue 先标记并留言若 14 天内无人反馈则关闭从而持续压缩积压backlog。4.8 标签Labels如何管理仓库对标签的访问控制很少总体上人人可编辑——请做好全球公民标签并非越多越好新增标签前要考虑是否会造成混淆。例如在已有优先级标签的情况下再新建一个P1标签就会令人困惑拿不准时先询问负责的团队经理。从仓库现状看dotnet/runtime 已经引入基于机器学习的自动打标签根据 .github/labeler-readme.md仓库使用 dotnet/issue-labeler 系列的五个工作流labeler-predict-issues.yml、labeler-predict-pulls.yml、labeler-promote.yml、labeler-train.yml、labeler-cache-retention.yml其关键配置为LABEL_PREFIX设为area-即预测输出统一是area-*标签DEFAULT_LABEL设为needs-area-label当模型预测置信度低于阈值时改打该兜底标签这相当于无法自动分流 → 交给中央所有者人工处理的自动化入口仓库变量ISSUE_LABELER_PREDICTION_THRESHOLD默认0.05可覆盖预测置信度阈值PR 预测覆盖main与release/*分支仓库不对任何作者豁免打标签EXCLUDED_AUTHORS为空。4.9 dotnet/runtime 的分支政策是什么通用原则尽量不在仓库内直接建分支而是fork 后建分支任何临时创建的分支应在关联 PR 被合并或关闭后尽快删除任何非发布分支都可能随时被删除分支仅用于servicing 发布并由中央统一管理向这些分支合入代码受到集中监控与管理dotnet/runtime 位于 .NET Core 技术栈的最底层因此在发布末期通常比 .NET Core 其余部分更早进入冻结lockdown总体政策是 dotnet/runtime 内的所有代码在冻结日期与政策上保持一致。4.10 镜像Mirror政策是什么官方没有成文的镜像政策但有一条底线若镜像可能对更广泛的社区产生潜在影响请运用常识判断。4.11 Project Boards 与 ZenHub 政策是什么跨整个仓库共享的 ZenHub 部分主要是流水线pipeline即看板列名。新增或编辑这些流水线时最好广泛沟通并达成共识。4.12 Wiki 政策是什么该仓库禁用 Wiki。所有文档一律以仓库内的 Markdown 文件形式维护如本文所引用的 docs 目录体系。五、让自动化与流程协同运转从模板到状态机的完整链路把以上各节串起来一个 Issue/PR 从提交到解决的完整生命周期如下提交贡献者通过 Issue 模板提交内容。.github/ISSUE_TEMPLATE/config.yml 负责把 ASP.NET Core、.NET SDK、Entity Framework、Roslyn、WinForms、WPF 等不属于本仓库范围的问题重定向到对应仓库.github/ISSUE_TEMPLATE/01_bug_report.yml 则要求 Bug 报告必须包含描述、复现步骤、期望/实际行为、回归与否、配置信息等结构化字段为后续 triage 提供足够信息。自动分流issue-labeler 工作流.github/labeler-readme.md基于模型预测area-*标签预测置信度不足时打needs-area-label。新建 Issue 同时被打上untriagedPR 则直接获得area-*。通知area-*标签被应用后.github/policies/resourceManagement.yml 中的eventResponderTasks会按区域 对应的订阅者/团队其提及名单即 docs/area-owners.md 中各区域的 Owners并把如何订阅该区域的说明回复到条目中。TriageArea Owner 移除untriaged必要时分配里程碑完成三态转换untriaged→ 已 triage无标签→ 需要复核needs further triage。长期健康no-recent-activity/needs-author-action流程处理僵尸条目backlog-cleanup-candidate清理超陈旧 Issuelocker.yml 在关闭 30 天后锁定条目Draft PR 超 30 天自动关闭。此外.github/workflows/check-service-labels.yml、closed-issue-reference-check.yml 等额外工作流分别负责服务标签检查与已关闭 Issue 引用检查进一步把治理细节沉淀为代码。六、对贡献者与维护者的落地建议结合官方文档与仓库实现给出可直接套用的操作清单如果你是贡献者提交前先用 .github/ISSUE_TEMPLATE/config.yml 确认问题是否属于本仓库CoreCLR/Mono/底层库等否则到对应仓库提交提交后留意自动分配的area-*标签若需要多团队关注使用 Review 请求而非手动添加多个area-*若条目被标记needs author feedback/needs-author-action尽快补充信息任何新评论都会清除no recent activity作者评论还会触发needs further triage让团队重新评估想在特定区域被 通知无需 committer 权限按 docs/area-owners.md 与 docs/infra/automation.md 说明订阅即可不要在已关闭的条目上继续讨论——它会在 30 天后被锁定请新建 Issue。如果你是维护者 / Area Owner及时移除untriaged完成 triage切换area-*时务必重新补上untriaged发布收尾与 servicing 期间为条目设置 3 段式里程碑如3.0.0、3.0.2需要他团队协助时用 Review 请求保持每条目恰好 1 个area-*新增标签前评估歧义与团队经理沟通后再动手所有标签/里程碑都是全仓库共享资源。综上dotnet/runtime 的 Issue/PR 治理并非一套静态规则而是文档规范 机器人自动化 区域负责人制三者咬合的工程实践规范定义语义docs/issues-pr-management.md自动化把语义固化为可执行策略.github/policies/resourceManagement.yml、.github/workflows/locker.yml、issue-labeler 工作流区域负责人制则负责语义之外的人工判断。这一模式对任何大型开源仓库的协作治理都极具参考价值。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dotnet/runtime Issue 与 Pull Request 治理实践：标签规范、Triage 流程、里程碑与自动化运维指南
dotnet/runtime Issue 与 Pull Request 治理实践标签规范、Triage 流程、里程碑与自动化运维指南【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtimedotnet/runtime 是 .NET 的跨平台运行时仓库覆盖 CoreCLR、Mono、NativeAOT、底层库等社区与多个工程团队在同一仓库中协同工作。本篇技术指南系统梳理该仓库官方发布的 Issue 与 PR 管理规范从area-*标签体系、untriaged/needs further triage状态机到里程碑milestone策略、分支政策与自动化工具体系。读完本文你既能以贡献者身份理解如何让一个 Issue/PR 被正确分流与响应也能以仓库维护者身份掌握如何用标签、里程碑与机器人自动化保持大型仓库健康运转。一、核心理念与原则大型公共仓库的协作根基dotnet/runtime 的 Issues 与 Pull Requests 是跨团队、跨社区的共享资源。官方文档将其治理目标凝练为四条原则保持一个社区/一个团队的整体感不要让多个子团队各自为政导致贡献者无所适从用自动化给进站/在途的 Issue 与 PR 打标签从而实现问责制accountability每个条目都要有人负责area-*标签应与某个具体的社区/团队对应标签即职责契约在同一个area-*内部允许各团队保留适合自己的局部实践全局统一规范 局部灵活度并存。这套原则的落地产物就是下文通用策略中的一整套标签状态机与机器人自动化。需要强调的是原则与规范是人的约定而真正的高效运转依赖仓库中实际的自动化配置文件见第六节二者共同构成了 dotnet/runtime 的 Issue/PR 治理闭环。二、通用策略标签、Triage 与锁定的核心规则以下是 dotnet/runtime 全员必须遵守的公共策略也是理解整个治理体系的关键规则说明自动打area-*标签所有新提交的 Issue 与 PR 都会被自动标记一个area-*标签机器人同时会给新建的 Issue不含 PR打上untriaged标签恰好 1 个area-*标签每个 Issue / PR 应且只应有1 个area-*标签避免多团队归属不清Triage 完成标志当untriaged标签被移除该 Issue 即视为已 triageneeds further triage标签用于标记需要以后再仔细看一次的条目换区必须重新 Triage当area-*标签被切换时必须重新添加untriaged标签防止 Issue 在并未真正被新区域负责人 triage 的情况下误入已 triage状态未来可能由机器人自动强制这一行为中央仓库所有者兜底当自动化无法判断归属区域时无法获得area-*标签的 Issue 与 PR 由中央仓库所有者负责 triage 与分发融合技术标签命名凡涉及多个合并技术的area-*标签需追加对应src/子目录名。例如area-Infrastructure之外还有area-Infrastructure-libraries、area-Infrastructure-coreclr、area-Infrastructure-installer标签与里程碑共享所有area-*标签、所有里程碑都是全仓库共享的新增/修改时需考虑整个 dotnet/runtime 的生态做负责任的公民关闭后 30 天锁定已关闭的 Issue 与 PR 在30 天无活动后被锁定lock。原因很简单关闭条目上的新评论极易被遗漏官方鼓励用户新建 Issue而不是在已关闭条目上继续讨论关于30 天锁定仓库中的实际自动化工作流给出了精确实现.github/workflows/locker.yml每天定时运行cron37 8 * * *以daysSinceClose: 30与daysSinceUpdate: 30为默认参数锁定过期条目同时监听reopened事件一旦 Issue/PR 被重新打开且处于锁定状态会自动执行解锁保证关闭-锁定不会阻碍新讨论的启动。三、需要 Area Owner 亲自出手的场景自动化只能完成分流与标记真正的 triage 决策必须由人完成。官方文档明确了两个强制管理场景untriaged标签的 Issue所有带untriaged标签的 Issue 都被视为未 triage。接近产品发布时各团队会被要求完成 triage若想留待日后细看可改用needs further triage标签。发布收尾release endgame与 servicing 期间针对特定版本的 Issue 与 PR 会被要求设置里程碑milestone以便按版本追踪与燃尽burndown。四、FAQ 详解从 Triage 定义到分支/镜像/看板政策官方 FAQ 是理解各项具体政策的最佳入口以下逐条展开并补充仓库证据。4.1 什么才算已 triage的 Issue默认情况下所有新提交的 Issue 都会被打上untriaged标签该标签存在即意味着需要 Area Owner 采取行动。在发布周期的特定时点Area Owner 可能被要求集中完成 triage。Triage 的最简形式就是移除untriaged标签但对大多数团队而言triage 意味着为 Issue 分配一个打算解决的里程碑。所有新条目还必须获得area-*标签——任何未获得area-*标签的 Issue 同样被视为未 triage。最佳实践当 Issue 从一个区域转移到另一个区域时应重新添加untriaged标签以提示新区域负责人需要在新的上下文中重新评估。4.2 里程碑Milestone如何处理里程碑标记是release endgame 与 servicing 期间的必要动作当发布进入 Issue 燃尽burndown阶段仓库所有者会要求 Area Owner 标记出应考虑纳入当前版本的 Issue。Servicing 的 PR应先添加major.minor.x形式的里程碑如3.0.x一旦确定具体 servicing 版本号再为 PR 补充精确里程碑如3.0.2。不设里程碑的 Issue 通常也是可接受的是否要求由各 Area Owner 自行决定没有里程碑 ≠ 未 triage。命名规范优先使用 3 段式里程碑名如3.0.0而非3.0以与其他仓库保持一致并便于报表统计。4.3 只有一个area-*标签时如何请求多个团队审查历史上给 Issue/PR 打多个area-*标签是为了吸引多个团队的注意。但为保障问责制现在每个条目只保留 1 个area-*标签若确实需要多团队关注请通过 Review 请求添加审阅人的方式而不是添加对方的area-*标签。4.4 dotnet/runtime 的通知机制是怎样的跟踪与关注 Issue 变化使用GitHub 默认通知系统。此外还有一个机器人当area-*标签被应用时发送通知。但它不会自动通知 Area Owner——因为并非所有人都想要这类通知。想接收区域通知的贡献者请按 docs/area-owners.md 中的说明自行订阅不需要具备 committer 权限。值得说明的是从仓库现状看docs/area-owners.md 已经扩展为一份完整的区域负责人名录覆盖 100 个area-*如area-System.Text.Json、area-GC-coreclr、area-NativeAOT-coreclr、os-*如os-android、os-wasi、arch-*如arch-loongarch64、arch-riscv标签的 Lead 与 Owners并额外列出了一批社区 Triage 成员Community Triagers——他们虽不隶属于具体区域但拥有协助路由和标记 Issue/PR 的权限。该文件明确指出编辑它并不会更新dotnet-policy-service用于区域通知的映射真正的映射在 .github/policies/resourceManagement.yml 中多数区域使用 GitHub Team 接收通知社区成员若想订阅可提交 PR 更新该配置文件参见 docs/infra/automation.md。4.5 PR 如何被打上标签与里程碑鉴于 dotnet/runtime 的规模所有 PR 都会被自动分配area-*标签此外部分 PR 会依据 release endgame 与 servicing 要求被附加里程碑。4.6 仓库的日常持续管理由谁负责仓库设有一位团队经理M2可能轮值对下列全局健康活动负责对无法自动分流的新条目进行 triage 并补打area-*标签公共基础设施common infrastructure的跟踪服务级别协议SLA跟踪——确保响应性与仓库健康发布 Issue 燃尽release issue burn down。而各个 Area Owner 则在其负责区域内按自己团队的方式管理各自的 PR 与 Issue。4.7 还有哪些其他 Issue 自动化可用官方文档描述了一套作者反馈自动流程当 Issue 因缺少作者提供的信息而无法推进时可打上needs author feedback标签若此后14 天内作者没有新评论机器人会添加no recent activity标签并附一条说明再过7 天仍无作者评论机器人会关闭该 Issue 或 PR期间任何人的评论都会清除no recent activity若评论来自作者本人则needs author feedback也会被清除并补上needs further triage以便团队重新看到它。从当前仓库的自动化配置看这套流程已在 .github/policies/resourceManagement.yml 中以GitOps.PullRequestIssueManagement的scheduledSearches方式落地实际使用的标签名为needs-author-action与no-recent-activity时间窗为14 天标记 再 14 天关闭——以配置文件为准它比文档描述的时间窗更长、更保守。该配置还实现了Draft PR 自动清理打开超过 30 天无活动的 Draft PR 会被自动关闭。此外仓库还有backlog-cleanup-candidate标签驱动的陈旧 Issue 清理流程详见 docs/issue-cleanup.md对超过约 4.5 年noActivitySince: days: 1644无活动的开放 Issue 先标记并留言若 14 天内无人反馈则关闭从而持续压缩积压backlog。4.8 标签Labels如何管理仓库对标签的访问控制很少总体上人人可编辑——请做好全球公民标签并非越多越好新增标签前要考虑是否会造成混淆。例如在已有优先级标签的情况下再新建一个P1标签就会令人困惑拿不准时先询问负责的团队经理。从仓库现状看dotnet/runtime 已经引入基于机器学习的自动打标签根据 .github/labeler-readme.md仓库使用 dotnet/issue-labeler 系列的五个工作流labeler-predict-issues.yml、labeler-predict-pulls.yml、labeler-promote.yml、labeler-train.yml、labeler-cache-retention.yml其关键配置为LABEL_PREFIX设为area-即预测输出统一是area-*标签DEFAULT_LABEL设为needs-area-label当模型预测置信度低于阈值时改打该兜底标签这相当于无法自动分流 → 交给中央所有者人工处理的自动化入口仓库变量ISSUE_LABELER_PREDICTION_THRESHOLD默认0.05可覆盖预测置信度阈值PR 预测覆盖main与release/*分支仓库不对任何作者豁免打标签EXCLUDED_AUTHORS为空。4.9 dotnet/runtime 的分支政策是什么通用原则尽量不在仓库内直接建分支而是fork 后建分支任何临时创建的分支应在关联 PR 被合并或关闭后尽快删除任何非发布分支都可能随时被删除分支仅用于servicing 发布并由中央统一管理向这些分支合入代码受到集中监控与管理dotnet/runtime 位于 .NET Core 技术栈的最底层因此在发布末期通常比 .NET Core 其余部分更早进入冻结lockdown总体政策是 dotnet/runtime 内的所有代码在冻结日期与政策上保持一致。4.10 镜像Mirror政策是什么官方没有成文的镜像政策但有一条底线若镜像可能对更广泛的社区产生潜在影响请运用常识判断。4.11 Project Boards 与 ZenHub 政策是什么跨整个仓库共享的 ZenHub 部分主要是流水线pipeline即看板列名。新增或编辑这些流水线时最好广泛沟通并达成共识。4.12 Wiki 政策是什么该仓库禁用 Wiki。所有文档一律以仓库内的 Markdown 文件形式维护如本文所引用的 docs 目录体系。五、让自动化与流程协同运转从模板到状态机的完整链路把以上各节串起来一个 Issue/PR 从提交到解决的完整生命周期如下提交贡献者通过 Issue 模板提交内容。.github/ISSUE_TEMPLATE/config.yml 负责把 ASP.NET Core、.NET SDK、Entity Framework、Roslyn、WinForms、WPF 等不属于本仓库范围的问题重定向到对应仓库.github/ISSUE_TEMPLATE/01_bug_report.yml 则要求 Bug 报告必须包含描述、复现步骤、期望/实际行为、回归与否、配置信息等结构化字段为后续 triage 提供足够信息。自动分流issue-labeler 工作流.github/labeler-readme.md基于模型预测area-*标签预测置信度不足时打needs-area-label。新建 Issue 同时被打上untriagedPR 则直接获得area-*。通知area-*标签被应用后.github/policies/resourceManagement.yml 中的eventResponderTasks会按区域 对应的订阅者/团队其提及名单即 docs/area-owners.md 中各区域的 Owners并把如何订阅该区域的说明回复到条目中。TriageArea Owner 移除untriaged必要时分配里程碑完成三态转换untriaged→ 已 triage无标签→ 需要复核needs further triage。长期健康no-recent-activity/needs-author-action流程处理僵尸条目backlog-cleanup-candidate清理超陈旧 Issuelocker.yml 在关闭 30 天后锁定条目Draft PR 超 30 天自动关闭。此外.github/workflows/check-service-labels.yml、closed-issue-reference-check.yml 等额外工作流分别负责服务标签检查与已关闭 Issue 引用检查进一步把治理细节沉淀为代码。六、对贡献者与维护者的落地建议结合官方文档与仓库实现给出可直接套用的操作清单如果你是贡献者提交前先用 .github/ISSUE_TEMPLATE/config.yml 确认问题是否属于本仓库CoreCLR/Mono/底层库等否则到对应仓库提交提交后留意自动分配的area-*标签若需要多团队关注使用 Review 请求而非手动添加多个area-*若条目被标记needs author feedback/needs-author-action尽快补充信息任何新评论都会清除no recent activity作者评论还会触发needs further triage让团队重新评估想在特定区域被 通知无需 committer 权限按 docs/area-owners.md 与 docs/infra/automation.md 说明订阅即可不要在已关闭的条目上继续讨论——它会在 30 天后被锁定请新建 Issue。如果你是维护者 / Area Owner及时移除untriaged完成 triage切换area-*时务必重新补上untriaged发布收尾与 servicing 期间为条目设置 3 段式里程碑如3.0.0、3.0.2需要他团队协助时用 Review 请求保持每条目恰好 1 个area-*新增标签前评估歧义与团队经理沟通后再动手所有标签/里程碑都是全仓库共享资源。综上dotnet/runtime 的 Issue/PR 治理并非一套静态规则而是文档规范 机器人自动化 区域负责人制三者咬合的工程实践规范定义语义docs/issues-pr-management.md自动化把语义固化为可执行策略.github/policies/resourceManagement.yml、.github/workflows/locker.yml、issue-labeler 工作流区域负责人制则负责语义之外的人工判断。这一模式对任何大型开源仓库的协作治理都极具参考价值。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考