编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载导读Dart SDK 是一个由多个子团队共同维护、包含大量工具与库的巨型单仓monorepo。为了让一个庞大的 issue 追踪器保持有序Dart 团队建立了一套以标签label为核心的规范化协作流程。本文以仓库文档 docs/How-the-issue-tracker-works.md 为骨架完整讲解这套机制任务如何指派、标签如何分类area / type / priority / os / customer / closed 等、issue 如何分诊与关闭、以及如何用查询快速筛选出需要关注的问题。读完本文你将能读懂 Dart SDK 仓库中任意一个 issue 的标签含义也能了解如何规范地提交、分诊与推进一个 issue。一、为什么需要一套 Issue 追踪规范Dart SDK 仓库README.md包含大量由不同子团队维护的工具和库VM、JS 编译器、Wasm 编译器、静态分析器analyzer、核心库等等。把它们放在同一个仓库里可以方便地在一个改动中同时落地跨组件的变更但代价是 issue 追踪器会变得庞大而难以驾驭。为了管理这种复杂性Dart 团队使用了一套统一的标签labels与策略policies。标签的核心价值在于缩小范围帮助每个团队或个人快速定位与自己相关的 issue 子集量化统计对相关问题计数用于比较不同领域的工作量或观察长期趋势沟通状态帮助更大的社区了解团队正在做什么以及自己提交的 bug 处于什么状态。为了让标签名保持一致标签命名采用 kebab-case 规范小写单词、用连字符分隔。由于标签数量众多大多数标签是分门别类的标签名的第一个单词通常就是类别名例如area-、type-、os-、customer-、closed-。二、任务指派模型Assignment拉取式协作与许多现代软件团队一样Dart 团队使用**拉取模型pull model**来分配任务大多数 issue 只被指派给一个团队通过下方area-标签表达而不是主动指派给某个个人当某个人开始实际处理某个 issue 时他会把 issue 指派assign给自己因此如果你看到一个 issue 上挂着某个人的名字通常意味着这个 issue 正在进行中。不过这个推断并不总是成立有时 issue 被指派给某人只是因为团队已经预判将由这个人修复但他还没开工有时工作暂停甚至暂停很久被指派者可能也不会主动取消自己的指派。所以在解读指派状态时需要结合 issue 的评论、时间线与标签综合判断。三、标签体系全览3.1 Area 标签area-归属团队area-标签是 Dart 团队最关心的主标签。每个 area 标签定义一个子团队有时只有一个人该团队负责拥有这些 issue并负责解决它们或者把它们转交给其他 area。关键约束有两条每个 issue 必须有且只有一个 area 标签。实践表明当 issue 没有 area 或挂了多个 area 时责任归属不清问题会从缝隙中漏掉如果一个 issue 需要多个团队协作那么它应该被拆分成两个或多个 issue每个 issue 只归属于一个 area。仓库里还配套了专门的area-meta标签meta-issue 用于把一组 issue 聚合起来以协调跨团队的协作。meta-issue 通常在高层次上描述整体计划然后链接到与之相关的具体 issue。由于没有哪个团队对area-meta负责这类 issue还必须指派给一个具体的人由他负责跟踪各个关联 issue 的状态并在全部完成后关闭这个 meta-issue。延伸从仓库 docs/Triaging-Dart-SDK-issues.md 可以看到分诊的第一步就是处理没有 area 的 issue通过 SDK triage query 找出它们然后为每个 issue 添加正确的area-*标签如果 issue 属于area-core-library还需要进一步添加对应的library-*标签。3.2 Browser 标签Web 产品受影响浏览器对于 Web 产品的 issueBrowser标签用于追踪该 issue 影响的浏览器。但团队并不会总是严谨地打上这个标签所以缺少该标签可能意味着所有浏览器都受影响也可能意味着还没调查过受影响的浏览器存在该标签也不一定代表其他浏览器就完全没有问题。3.3 Customer 标签customer-关键合作伙伴如果某个 issue 严重影响关键合作伙伴用customer-标签记录受影响方这有助于团队优先处理该 issue并确保合作伙伴持续知情。该标签还有一个重要用途记录被其他 area 拥有的 issue 所影响的 Dart 子团队。例如有人提交了一个VM 未能正确显示某个静态错误的 bug那么这个 issue 很可能同时带有area-cfe因为前端front end团队负责静态错误customer-vm因为错误没有在 VM 这一层被正确呈现出来。3.4 OS 标签os-受影响操作系统与 Browser 标签类似os-标签记录 issue 在哪些操作系统上显现。同样地团队对此并不总是十分严谨标签的存在表示已知该 issue 在对应系统上确实有问题但可能仍会影响其他操作系统。3.5 Priority 优先级标签团队的处理紧迫度优先级标签表达团队解决该 issue 的紧迫程度共分四级标签含义典型场景P0世界着火了多个产品不可用、暴露个人信息的安全问题、严重的性能回退。需要的团队成员应放下手头一切工作去修复P1有东西坏了单个项目不可用或出现大量测试失败。应在恢复正常工作之前修复P2一切照常普通的 issue 和功能请求可以排入日程而无需特别紧迫P3有机会再说外观性问题或轻微 bug无紧迫性、可见度低属于打磨或锦上添花类几乎每个 issue 都应有且仅有一个优先级标签。延伸关于优先级的实际运用docs/Triaging-Dart-SDK-issues.md 给出了更细的团队内操作口径——P0 在 dev 渠道会阻塞发布、在发布渠道值得做一次补丁dot发布P1 计划在正在进行中的发布内完成P2 是之后某次发布的重要工作最终应该完成P3 是也许某一天并且 P3 是优先考虑以closed-not-planned关闭的候选。该文档还强调了一个重要原则如果所有东西都是 P0那就没有 P0——优先级应当由团队与产品管理共同判断并随 issue 的解决与新增而动态调整。对于area-vm和 IO 库library-io的 issueVM 团队每周至少分诊一次分诊时还会结合优先级指派里程碑并打上triaged标签。3.6 Type 类型标签type-问题的性质type-标签对问题或所需工作的性质进行分类共七种标签含义type-bug系统当前行为错误且并非有意为之。可能严重到崩溃也可能是更微妙的错误行为但通常应是几乎任何用户都不想要的明显错误type-code-health对工具与工作流内部改动使其更整洁、更简单、更易维护用户不可见type-documentation请求新增或改进文档。由于 dartlang.org 等高层级文档托管在其它仓库这类标签不算常见多用于 API 级 doc 注释type-enhancement对工具提出具体改动但并非 bug 的请求。包括新特性、既有功能的优化以及当前行为虽符合设计但可能不再满足需求的改动。大多数涉及改代码的 issue 都会打这个标签type-performance行为正确但效率不佳。性能涉及多个维度执行时间、内存占用、启动时间等type-security与用户隐私或恶意攻击者接管系统相关的最可怕的一类问题type-task需要完成但结果不是代码或文档改动的工作例如搬运数据、发布包、调整服务器或其它基础设施任何一个 issue 应有且仅有一个 type 标签如果没有它很可能还在等待分诊。延伸从 docs/Triaging-Dart-SDK-issues.md 的分诊步骤看分诊人会先判断 issue 是 bug、增强请求、性能问题、一般性问题还是文档问题然后打上对应的 type 标签。3.7 Area-specific 标签子团队专属标签子团队常常拥有只在特定产品或系统内有意义的专属标签这些标签以该团队的 area 名为前缀例如devexp-、vm-等。这些标签由对应团队自行管理包括如何使用、含义是什么、何时可以移除。3.8 其它杂项标签文档中还列出了一批其它常见标签blocked团队因外部约束或其它团队而无法推进的 issue。应有一条评论解释被什么阻塞并在可能时直接链接到阻塞它的另一个 issue。cla: yes / cla: no在接收非 Google 贡献者的改动之前他们必须签署贡献者许可协议CLA。团队用 bot 请求贡献者签署并追踪状态用这两个标签标记。contributions-welcome标记那些已被验证为正当、且所属子团队欢迎外部开发者贡献的 issue。解决这类 issue 不应过于困难也不应需要大量代码。该标签通常打在 bug 和文档请求上而非功能请求上——因为前者的评审与维护成本更低。merge-to-dev / merge-to-stable用于追踪把某个改动从 main 分支 cherry-pick 到某个发布分支的请求。needs-info需要更多信息。常见于最初的 issue 描述不清楚有时也表示团队已做了部分修复工作希望别人帮忙验证方案。打上该标签时应同时写评论说明需要什么信息或澄清。这类 issue 容易因为无法推进、提交者离开而变陈旧。四、Closed 关闭标签closed-说明关闭原因在理想世界中每个提交的 issue 都唯一对应一个真实、重要的问题每个关闭的 issue 都已被修复。但现实是有些 issue 是重复的、过于令人困惑的或者团队实在没有时间处理。团队认真对待每个 issue但也必须在有限时间内最大化价值因此需要权衡取舍。如果 issue 被关闭但没有 closed 标签通常意味着它已被修复——此时一般应附上修复该 issue 的提交链接或说明性评论。否则就应该打上下列 resolution 标签之一并通常附带解释为何如此解决的评论标签含义与处理建议closed-as-intended最有争议的关闭原因之一当前行为正是团队想要的虽然明显不是提交者想要的。关闭者应尽量写评论解释为何偏好当前行为——往往是其它系统或约束限制或是在想要不同东西的用户之间做的权衡closed-cannot-reproduce无法复现。可能是问题在有人查看之前已被修复也可能是问题仍在但调查者没能让它显现。如果你提交的 issue 因此被关闭但它仍然有效建议补充更详细的复现步骤以便重新打开closed-duplicate已有另一个 issue 在追踪该变更。关闭时应评论链接到那个重复 issue。判断重复往往依赖对内部架构与实现细节的理解两个 issue 看起来相同但可能需要不同方式解决反之两个看似不同的 issue 可能根因相同。因为 issue 被当作工作单元追踪只要一个单一改动就能解决两个 issue就视为重复——关闭一个不代表丢弃其中的信息与讨论。去重时通常保留更早的那个除非新 issue 明显更有用closed-invalid无法理解 issue 描述想表达什么有时用户会为完全无关的产品提交 issue。团队通常会尽量避免使用它而是改用needs-info向提交者请求澄清closed-obsoleteissue 存在已久且无活动没人做方案、也没人强烈要求。问题可能已被无意修复。关闭是清僵尸但随时可以重新打开或新建。该标签经常由人手动打也会由 bot 按过期策略自动打closed-not-planned请求有效但不预期会发生。可能因为更高优先级的功能与其直接冲突也可能只是没有时间。这不意味着永远不会做——优先级与容量会随时间变化——但关闭更能清晰传达团队当前的优先级五、分诊工作流Triage Workflow结合 docs/Triaging-Dart-SDK-issues.md一个标准的分诊流程大致是用 SDK triage 查询找出没有 area 标签的 issue判断 issue 是否与 SDK 中的代码相关是则添加正确的area-*标签若属于area-core-library再补充正确的library-*标签若明显是 bug 或 enhancement可选地打上type-bug或type-enhancement若 issue 与其它dart-lang项目/包相关用 Transfer issue 链接把它转移到正确的仓库分诊人还可以通过标签订阅工具在打上自己关心的标签时收到邮件通知。其中needs-info标签有配套的自动化带该标签的 issue 由 no-response bot 分诊如果提交者在14 天内未回应bot 会自动关闭该 issue注意这与原文档中60 天无活动可能关闭的旧口径不同当前以 docs/Triaging-Dart-SDK-issues.md 记载的 14 天自动化策略为准。如果你关心某个 issue 的存续请尽快提供它需要的信息。此外团队还在实验分诊自动化你可能会看到dart-github-bot的评论这与团队的自动化调研相关现阶段可以安全忽略。六、常用查询Queries把标签变成可执行列表标签的价值最终体现在查询上。原文档给出了四个非常实用的查询思路可以帮助团队和社区快速定位问题没有 area 的 issue列出所有打开的、且不带任何area-*标签的 issue即最需要分诊的问题没有优先级的 issue列出所有打开的、且不带 p0/p1/p2/p3 标签的 issue没有 type 的 issue列出所有打开的、且不带type-bug/type-code-health/type-documentation/type-enhancement/type-performance/type-security/type-task标签的 issue没有指派人的 meta-issue列出所有打开的、带area-meta标签但没有 assignee 的 issuemeta-issue 必须有人负责因此这类查询很有价值。这些查询在 GitHub issues 界面中通过is:issue is:open -label:...或no:assignee等过滤条件组合实现是分诊和社区贡献者筛选工作的重要入口。七、与提交、发布流程的衔接这套 issue 机制并非孤立存在它与仓库的变更流程深度咬合分支与发布merge-to-dev/merge-to-stable标签对应着 docs/Branches-and-releases.md 中描述的四个主要分支main / dev / beta / stable与约两个月一个周期的发布节奏。普通改动在 main 上开发只有在紧急情况下才把关键修复 cherry-pick 到 dev / beta / stable 渠道具体操作细节见 docs/Cherry-picks-to-a-release-channel.md——其中明确要求 cherry-pick 的提交信息必须包含 Issue 描述、修复内容、为什么需要 cherry-pick、风险评估以及原始 issue 链接stable 渠道的 cherry-pick 还必须附带 CHANGELOG.md 条目。破坏性变更docs/process/breaking-changes.md 要求任何破坏性变更的第一步就是在 issue 追踪器中新建一个带breaking-change-request标签的 issue说明预期的行为变更如果变更被回滚还需以roll-back-request标签建立回滚请求 issue。版本号佐证tools/VERSION 的注释详细描述了版本号如何随发布与 cherry-pick 递增例如向 stable 渠道做 cherry-pick 时 PATCH 加 1与 issue 的优先级、merge-to-*标签背后的发布决策形成闭环。八、在哪里提交 issue分仓库提交并不是所有 Dart 相关问题都应该提交到 sdk 仓库。由于 Dart 分散在多个 GitHub 仓库中开发docs/Filing-Dart-issues.md 建议按组件选择正确的 issue 追踪器组件Issue 追踪器SDK 核心语言、VM、dart2js、Analyzer、调试器/Observatorydart-lang/sdkDartPad 编辑器dart-lang/dart-padPub 工具dart-lang/pubdartfmt 工具dart-lang/dart_styleDartdoc 工具dart-lang/dartdoctest 库dart-lang/testAngularDartdart-lang/angularwww.dartlang.org 网站dart-lang/site-www以上仓库 URL 均为外部平台地址提交时请按官方链接跳转。提交前建议先在 docs/README.md 与 docs/How-the-issue-tracker-works.md 中确认对应组件与标签约定并用本文第四节介绍的查询确认你的问题是否已被追踪以避免重复提交。结语Dart SDK 的 issue 追踪体系本质上是一套以标签为语言的协作协议area-定归属、type-定性质、priority 定紧急度、os-/customer-/Browser 定影响面、closed-定结局、needs-info/blocked/merge-to-*等则表达流转状态。理解这套协议无论是作为团队内部成员分诊、作为外部贡献者寻找contributions-welcome的切入点还是作为用户追踪自己 bug 的状态都能事半功倍。若你希望参与维护这些文档仓库欢迎通过 CONTRIBUTING.md 描述的方式贡献更新。赞分享编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载相关推荐PowerShell 仓库 Maintainer 机制全解角色职责、Issue 标签体系与 PR 合并工作流规范PowerShell 仓库 Maintainer 机制全解角色职责、Issue 标签体系与 PR 合并工作流规范 本文以 PowerShell 开源仓库的 M编程语言语言运行时CLIReact Native Elements 标签体系指南Issue 与 Pull Request 的分类与协作规范React Native Elements 标签体系指南Issue 与 Pull Request 的分类与协作规范 标签Label是开源仓库协作的交通标UI组件移动开发前端etcd 项目 Issue 分类分诊指南标签体系、优先级评定与社区协作流程etcd 项目 Issue 分类分诊指南标签体系、优先级评定与社区协作流程 导读 本文基于 Documentation/contributor guide/t后端数据库分布式数据库KV存储云原生服务注册发现配置中心创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考