企业官网建设流程全解析

• 编程语言
• 编译器
• 语言运行时
• 标准库
• 开发工具

导读

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 产品的 issue，Browser标签用于追踪该 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 的紧迫程度，共分四级：

几乎每个 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）的 issue，VM 团队每周至少分诊一次，分诊时还会结合优先级指派里程碑并打上triaged标签。

3.6 Type 类型标签（"type-"）：问题的性质

type-标签对问题（或所需工作）的性质进行分类，共七种：

任何一个 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 标签之一，并通常附带解释为何如此解决的评论：

五、分诊工作流（Triage Workflow）

结合 docs/Triaging-Dart-SDK-issues.md，一个标准的分诊流程大致是：

1. 用 SDK triage 查询找出没有 area 标签的 issue；
2. 判断 issue 是否与 SDK 中的代码相关：是，则添加正确的area-*标签；
3. 若属于area-core-library，再补充正确的library-*标签；
4. 若明显是 bug 或 enhancement，可选地打上type-bug或type-enhancement；
5. 若 issue 与其它dart-lang项目/包相关，用 "Transfer issue" 链接把它转移到正确的仓库；
6. 分诊人还可以通过标签订阅工具，在打上自己关心的标签时收到邮件通知。

其中needs-info标签有配套的自动化：带该标签的 issue 由 no-response bot 分诊，如果提交者在14 天内未回应，bot 会自动关闭该 issue（注意：这与原文档中"60 天无活动可能关闭"的旧口径不同，当前以 docs/Triaging-Dart-SDK-issues.md 记载的 14 天自动化策略为准）。如果你关心某个 issue 的存续，请尽快提供它需要的信息。

此外，团队还在实验分诊自动化：你可能会看到@dart-github-bot的评论，这与团队的自动化调研相关，现阶段可以安全忽略。

六、常用查询（Queries）：把标签变成可执行列表

标签的价值最终体现在查询上。原文档给出了四个非常实用的查询思路，可以帮助团队和社区快速定位问题：

1. 没有 area 的 issue：列出所有打开的、且不带任何area-*标签的 issue（即最需要分诊的问题）；
2. 没有优先级的 issue：列出所有打开的、且不带 p0/p1/p2/p3 标签的 issue；
3. 没有 type 的 issue：列出所有打开的、且不带type-bug/type-code-health/type-documentation/type-enhancement/type-performance/type-security/type-task标签的 issue；
4. 没有指派人的 meta-issue：列出所有打开的、带area-meta标签但没有 assignee 的 issue（meta-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 追踪器：

（以上仓库 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 描述的方式贡献更新。

• 编程语言
• 编译器
• 语言运行时
• 标准库
• 开发工具