Flutter 贡献指南：如何找到最有价值的工作（P0–P3 优先级体系与工作清单全解）

本文基于 Flutter 官方贡献文档 What-should-I-work-on.md 展开，系统讲解 Flutter 项目为贡献者设计的"一站式工作优先级清单"：从构建破坏、P0 回归、代码评审，到 P1/P2 问题与技术债务，再到按点赞数排序的社区热门问题。读完本文，你可以明确回答"现在最该做什么"，并理解背后 P0–P3 优先级标签、Triage 分诊机制与 OKR 跟踪方式是如何协同运转的。

这份指南要解决什么问题

在一个拥有数千个开放 issue、由 Google 员工与大量社区志愿者共同维护的开源项目中，"我该做哪件事"往往比"我该怎么做"更难。What-should-I-work-on.md 的开篇给出了它的设计目标：

本页试图成为"搞清楚当前最重要的事是什么"的一站式入口，让团队成员（贡献者）能够确定改进 Flutter 的更有效方式。

也就是说，这份清单不是需求列表，而是一套决策顺序：当你同时面对多个候选工作时，按清单从上到下依次判断，命中哪一条就优先做哪一条。下文按原文档的完整顺序逐条拆解，并结合仓库内 issue hygiene 规范、Triage 流程 和测试文档 补充每条背后的实现细节。

完整工作优先级清单

原文档给出的是一个 8 级优先级列表（原列表为编号 1 起的有序列表），这里完整继承并逐条展开。

第 1 优先级：构建破坏（Build breakage）

清单的第一项是修复构建破坏——即主干构建或 CI 失败的红色状态。原文档要求贡献者第一时间查看构建 dashboard 确认是否存在未处理的构建失败。这是整个优先级体系中最紧急的一类工作：主干红着的时候，所有其他变更都会被阻塞。

从仓库的 CI 配置可以印证这条优先级的重要性：仓库根目录的 .ci.yaml 定义了完整的 CI 任务矩阵，而 dev/bots/ 目录下维护着整套测试与构建自动化代码（如 dev/bots/test.dart、dev/bots/analyze.dart），Running-and-writing-tests.md 也明确说明要在本地以与 LUCI 完全相同的方式跑全仓分析和测试时，应执行 dart dev/bots/test.dart 和 dart --enable-asserts dev/bots/analyze.dart。当构建失败时，贡献者可以借助这两条命令在本地复现 CI 的行为，定位失败来源。

第 2 优先级：P0 问题（如严重回归）

第二个优先级是处理 P0 级 issue，典型例子是严重回归（serious regressions）。P0 的完整定义在 issue_hygiene/README.md 的 "Priorities" 一节中：

• 构建破坏、回归，或现有功能故障导致当前版本无法发布的问题；
• 影响团队开发速度、需要尽快偿还的重要技术债务；
• 正在阻塞（或即将阻塞）顶级客户（top-tier customer）的问题。

该文档还给出了几条量化约束，对贡献者排期很有参考价值：

• P0 数量通常少于 25 个（约一页搜索结果）。如果你要给自己贴 P0 标签，必须确认提交 issue 与接手人之间存在明确的"正面交接"（positive handoff）；
• P0 应在数周内解决，且必须在 GitHub 上保持每周更新；
• 正常工作周（非新年假期等）内，P0 会在一周一次的 "critical triage"（关键分诊）会议上被逐一审计，确保没有遗漏。

Triage 流程文档 中也有对应机制：每个团队都有自己的 P0 列表，团队需要确认每个 P0 都在取得进展，并且"每个 P0 issue 至少每周要有一条更新"。

第 3 优先级：指导有潜力的新贡献者（Mentoring）

第三个优先级出人意料地不是写代码，而是指导有潜力的新贡献者（mentoring promising new contributors）。这体现了一个成熟开源社区的理念：培养贡献者本身就是提升项目产出效率的杠杆——一个被良好引导的新人后续能持续贡献代码、评审和分诊。对社区贡献者而言，这也是进入 Flutter 核心团队工作圈子的自然入口：从帮助他人理解仓库结构、提交规范（可参考 Tree Hygiene 和 Issue Hygiene）开始，逐步承担实质性工作。

第 4 优先级：评审开放的 PR

第四个优先级是评审当前开放的 PR（code review of open PRs）。原文档附带了一个针对 flutter 组织所有开放 PR 的检索入口。这一点与 Triage 文档 中的 "PR triage process" 呼应：各团队应每周过一遍自己领域内的 PR，确认三件事——PR 有指定评审人、评审人已留下意见（否则应提醒）、贡献者提出的问题已得到回答。评审积压是大型开源项目最常见的隐性瓶颈，愿意做 review 的贡献者能直接缓解它。

第 5 优先级：P1 问题

P1 是"未影响顶级客户、也未破坏构建"的 bug 所能获得的最高优先级。Issue Hygiene 的定义是：P1 表示位于工作列表顶部的高优先级问题，除非 assignee 正在处理 P0（或其他 P1），否则 P1 通常都在被积极处理中，应在数月内解决并保持每月更新。

原文档将 P1 进一步拆为四个子类，值得逐一说明：

1. Flaky tests（不稳定测试）：原文档直接给了一个按 team: flakes 标签排序的检索视图。Issue Hygiene 的 "Flaky tests" 一节解释了其自动化机制：当一个测试出现 flake（偶发失败）时，系统会自动提一个带 team: flakes 标签的 P0 bug，随后由分诊流程指派优先级——任一时刻最 flaky 的测试应保持 P0，难以定位的 flake 可以降级（如降到 P1），但绝不能放任不管，解决后（哪怕"莫名其妙好了"）也要关掉。仓库中还配有专门的治理文档 Reducing-Test-Flakiness.md 供深入阅读。对贡献者来说，修复 flaky test 是"上手难度适中、价值明确、标签现成可查"的优质切入点。
2. Performance regressions（性能回归）：原文档建议查看 benchmark dashboard 寻找"尚未被报告的回归"，并结合已报告的 c: performance + c: regression 标签 issue 列表。这与 Roadmap 中持续强调性能（如 Impeller 渲染器迁移以降低 jank）的方向一致。
3. Other regressions（其他回归）：所有带 c: regression 标签的未修复回归。
4. Reducing technical debt（降低技术债务）：这是原文档明确列出示例的方向，包括提高 package:flutter 的测试覆盖率、编写新测试、以及修复代码中的 TODO。

针对"提高测试覆盖率"这一项，仓库文档给出了可操作的完整链路：

• 运行 flutter update-packages 后，package:flutter 的最新覆盖率数据会下载到 packages/flutter/coverage/lcov.info（Test-coverage-for-package-flutter.md 提醒：该数据不同步于你的 git 版本，存在版本偏差属正常现象）；
• 加完测试后可用 flutter test --merge-coverage test/material/dialog_test.dart 快速合并单测覆盖率到本地视图，其原理是把云端下载的 lcov.base.info 基线与本次运行数据合并后写回 lcov.info；
• 若要从头重算，可在 packages/flutter 下执行 flutter test --coverage。

测试本身的写法与组织方式（flutter_test 包、*_test.dart 命名、test/ 目录、按行为拆分文件等）详见 Running-and-writing-tests.md。

第 6 优先级：P2 问题（对应 Roadmap 的剩余领域）

原文档说明 P2 对应 Roadmap 中的剩余领域。当前仓库中的 Roadmap 是 2026 年版，主题包括：高保真多平台（完成 Impeller 在 Android 上的迁移、Wasm 成为 Web 默认）、GenUI 与 agentic apps、全栈 Dart（Dart Cloud Functions 等）、AI 重塑的开发者体验（MCP 服务器、与 AI 编码代理的协作）、可持续开源治理（Material/Cupertino 拆分为独立包、引擎与 CLI 的可扩展性）、现代语法与编译性能（Primary Constructors、Augmentations）、以及"至少 4 个稳定版 + 12 个 beta 版"的可预测发布节奏。

Issue Hygiene 对 P2 的定位是："我们认可重要，但不在工作列表顶部；它是新 issue 的默认级别，可能很长时间不修，有时先升到 P1 再处理，但并非必须。"原文档进一步列出 P2 中三类典型 bug 的检索标签：

• 带 a: annoyance 标签的"恼人"bug；
• 带 a: quality 标签的质量问题；
• 带 c: crash 标签的崩溃 bug。

这三类都是"不阻断发布、但持续消耗用户体验"的问题，适合作为 P1 清完之后长期推进的工作。

第 7 优先级：按 Thumbs-up 排序的 Issue

第七条让贡献者浏览按 👍 反应数排序的全部 issue，并附带了一句关键的策略性建议：

聚焦现有代码中的 bug，避免新增代码（Focus on bugs in existing code and avoid adding new code）。

这条建议与 Issue Hygiene 的 "Thumbs-up reactions" 一节形成闭环：团队把 thumbs-up 数量当作 issue 相对热度的一票（非唯一）输入，并维护"全部 issue / 功能请求 / bug"三个按 👍 排序的视图。"修 bug 优先于加功能"的原则背后，是 issue 卫生规范中"每个 issue 必须可执行（actionable）"、"为一切需要做的事提 bug、但不轻易承诺新平台/新功能"的整体治理思路——修复已存在代码的问题，投入产出比通常高于引入新代码面。

第 8 优先级：其他一切

最后一条是"其余所有事情"。原文档提醒在确定 bug 优先级时可参考它给出的一条外部排序建议（原文以链接形式引用）。换言之，当上面 7 条都没有命中时，贡献者可以凭判断力自行选择，但建议先对照 issue 的优先级标签与分诊状态，避免重复劳动——Issue Hygiene 的 "Assigning Issues" 一节解释了自认领机制：issue 未分配时即视为可被认领；只有正在做或已排期时才 assign 给自己（团队内部称之为 "licking the cookie"）；不再做了就要及时取消认领（"unlicking the cookie"），以免阻塞他人。

P0–P3 标签速查

把原文档引用的 Priorities 一节 汇总成表，方便按标签检索工作时快速对号入座：

标签	语义	解决时限与更新节奏	备注
P0	构建破坏/回归/顶级客户阻塞/影响团队速度的技术债务	数周内解决，每周更新	总量通常少于 25 个；critical triage 会议每周审计
P1	工作列表顶部的高优先级（flakes、性能回归、其他回归、技术债务）	数月内解决，每月更新	除 P0 外 bug 能获得的最高优先级
P2	认可重要但非顶部；对应 Roadmap 剩余领域	可能长期不修，可能先升 P1	新 issue 的默认级别
P3	当前认为相对不重要	不承诺时限	用 👍 作为是否升级的需求信号；仍通常接受符合规范的 PR

补充两点原文档体系中的细节：

• 对 P3 的"仍通常接受 PR"（assuming they follow our style guide and other rules），但带 would require significant investment 标签的 issue 可能需要远超一个 PR 的承诺（例如新增平台需要 CI 资源与长期维护负责人）；
• 升级/降级是常规操作。原文档明确写道："有时清单中的项会升级，例如某个 bug 先按 P2 提出，随后被确认为严重回归而升为 P0"。Triage 文档 也提到二级分诊（secondary triage）由责任团队定级，且每周进行。

优先级是如何被赋予的：Triage 机制

原文档有一句承上启下的话："在分诊（triage）过程中，bug 应按 P0–P3 标签定级，以匹配上文描述的顺序。"结合 docs/triage/README.md，完整的定级链路是：

1. 一级分诊（Primary triage，通常 1–2 个工作日内）：处理所有"无 team-* 标签、无 assignee、无 will need additional triage 标签"的 issue——清理描述、补齐格式、判断是否可执行、处理重复项，并按固定的路由决策树打上唯一一个 team-* 标签（如 team-engine、team-framework、team-tool、team-ios、team-android、team-web、team-linux、team-windows、team-macos、team-infra、team-accessibility、team-design、team-text-input、team-ecosystem、team-fluttergpu 等）；
2. 二级分诊（Secondary triage，通常每周一次）：责任团队查看自己的 incoming issue list 与 P0 列表，对 issue 关闭（说明原因）、打上优先级标签并加本团队的 triaged-* 标签、转派其他团队、退回一级分诊或升级到 critical triage；
3. 组织级分诊（Org triage，每周会议）：审计全量 P0（必须有人认领、一周内必须有进展）、will need additional triage 列表、自动滚动 PR、无主 PR 等，确保没有东西"从缝隙里漏下去"。

每个团队在仓库内都有标准化的"收件列表 + P0 列表 + PR 列表"三个查询入口（见 Triage 文档的 Links for teams 一节），贡献者可以直接复用这些查询模板，把自己负责领域的 backlog 拉出来做。

跨系统跟踪与 OKR 对齐

原文档中段还有两条容易被忽略但很重要的治理规则：

1. 一切以 GitHub 为准：其他 bug 系统中的问题也应在 GitHub 上跟踪（Issue Hygiene 的 "Coordinating between bug systems" 进一步说明：客户自有 bug 系统中的条目如果有指向 GitHub 的链接且已授权访问，团队会跟链跟进，但 GitHub 列表是 canonical 的）。
2. OKR 映射规则：OKR 应映射回上述清单，例如 OKR 应反映 Roadmap 覆盖的内容、预期的客户阻塞项等；某一季度的独有工作则体现为"一个带 milestone 与 assignee 的 bug"。

这与仓库的实际组织方式一致：Issue Hygiene 提到团队用 customer: product、customer: crowd 等标签把产品管理与高级领导层希望解决的问题送达对应工程团队，blocked 标签则用于"在另一个问题解决前无法推进"的条目——对用自己"已分配 issue 列表"驱动工作的人来说特别有用。

实战路径：从"我该做什么"到提交 PR

把全文收敛成一条可执行的贡献路径：

1. 先看红色：确认构建与 benchmark 没有未处理的破坏或新回归（对应第 1、5 优先级）；
2. 按标签拉列表：在 GitHub 上依次用 P0、P1、team: flakes、c: regression、a: annoyance、a: quality、c: crash 等标签检索未关闭 issue，或按 👍 排序浏览；
3. 确认状态：检查 issue 是否已有 assignee（未分配即视为可认领）、是否被标 waiting for response 或已进入 r: * 关闭流程；
4. 认领：将 issue assign 给自己（若没有权限，直接提 PR 也可）；
5. 本地复现与验证：
   • 单元测试：在目标包内 flutter test（单文件：flutter test path/to/x_test.dart），全仓 CI 等价验证：dart dev/bots/test.dart 与 dart --enable-asserts dev/bots/analyze.dart；
   • 涉及引擎改动时，可用 --local-engine 相关参数把测试指向本地构建的引擎（见 Running-and-writing-tests.md 中 "Locally built engines" 与 "Device lab tests with a local engine" 两节的完整命令示例）；
   • 补测试时可借助 --merge-coverage 即时查看覆盖率变化；
6. 提交 PR 并进入评审流：按 Tree Hygiene 提交；PR 会被对应团队纳入每周 PR 分诊，确保有评审人且意见得到回复。

相关文档索引

• 工作优先级清单（本文主体）：docs/contributing/What-should-I-work-on.md
• 优先级定义、标签体系与 issue 卫生：docs/contributing/issue_hygiene/README.md
• 一级/二级/组织级分诊流程与团队列表：docs/triage/README.md
• 基础设施团队分诊：docs/triage/Infra-Triage.md、Web 平台分诊：docs/triage/Flutter-Web-Triage.md
• 2026 Roadmap：docs/roadmap/Roadmap.md、旧版归档：docs/roadmap/[Archive]-Old-Roadmaps.md
• 运行与编写测试：docs/contributing/testing/Running-and-writing-tests.md
• package:flutter 测试覆盖率：docs/contributing/testing/Test-coverage-for-package-flutter.md
• 降低测试 flakiness：docs/infra/Reducing-Test-Flakiness.md
• 热门 issue 查看建议：docs/contributing/issue_hygiene/Popular-issues.md

小结

What-should-I-work-on.md 用一份 8 级清单回答了贡献者最实际的选择题：先保构建绿，再清 P0 与评审，然后按 P1（flakes、性能回归、其他回归、技术债务）、P2（Roadmap 对应的 annoyance/quality/crash）、👍 热度顺序推进，修旧优于加新。这套清单并不是孤立的建议，而是与 P0–P3 标签体系、每周 Triage 节奏、OKR-milestone-bug 的跟踪约定环环相扣——理解了这一整套机制，你在 Flutter 仓库里做的每一次"选任务"都会有据可依。