Triage Workflow
Find untriaged issues
Use the SDK triage query to find issues without area labels.
Assign area label
Does the issue relate to code in the SDK?
- Add the appropriate
area-*label to assign ownership to a team - If uncertain, add
area-metaand assign to someone who can coordinate
Add library label for core libraries
For
area-core-library issues, also add the specific library-* label:library-iolibrary-asynclibrary-core- etc.
Add type label (optional)
If obviously a bug or enhancement, add:
type-bugtype-enhancementtype-documentationtype-performance- Other type labels as appropriate
Set up email notifications for labels you care about using the Dart SDK email tool.
Issue Labels
Area Labels (area-*)
Area labels assign ownership to specific teams. Every issue must have exactly one area label. Special case:area-meta issues coordinate work across multiple teams:
- Should link to specific issues for each team
- Must be assigned to a person (not just a team)
- That person tracks progress and closes when all linked issues are complete
Priority Labels
Priority reflects team urgency, not user impact alone.| Priority | Meaning | Release Impact |
|---|---|---|
| P0 | Drop everything and fix it | Dev: blocks release, valid cherry-pick Stable: worthy of dot release |
| P1 | Planned for in-progress release | Should align with other work to ensure completion |
| P2 | Important work for later release | Should be done eventually |
| P3 | Maybe, someday | First candidates for closing as “not planned” |
Priority is the team’s opinion and may change as other issues are resolved or new ones appear. “If everything is P0, nothing is P0.”
During Cherry-Pick Season
When entering cherry-pick season for release X:- P0 issues: Only fixes that will be taken for release X
- P1-P3 issues: Either:
- Milestone changed to release X+1, or
- Priority downgraded to P2/P3 and milestone removed
Type Labels (type-*)
Every issue should have exactly one type label:| Type | Description |
|---|---|
type-bug | Current behavior is wrong and unintended |
type-enhancement | New feature or improvement to existing feature |
type-documentation | Documentation additions or improvements |
type-performance | Correct behavior but inefficient (time, memory, startup) |
type-security | Privacy or security vulnerabilities |
type-code-health | Internal improvements not visible to users |
type-task | Work that doesn’t change code (infrastructure, publishing, etc.) |
Closed Labels (closed-*)
Applied to closed issues to explain the resolution:| Label | Meaning | When to Use |
|---|---|---|
closed-as-intended | Current behavior is desired | Trade-offs or constraints prevent requested behavior |
closed-cannot-reproduce | Unable to verify the issue | Bug may be fixed or needs better reproduction steps |
closed-duplicate | Already tracked in another issue | Comment should link to the duplicate issue |
closed-invalid | Unclear or unrelated to Dart | Genuinely confusing or misfiled issues |
closed-obsolete | Long inactive with no progress | May be reopened if it becomes relevant again |
closed-not-planned | Valid but not expected to happen | Capacity or priority constraints |
If an issue is closed without a closed label, it’s assumed to be fixed. There should be a link to the fixing commit.
Other Important Labels
needs-info: Additional information needed from the reporter- Add a comment explaining what information is needed
- Bot will auto-close after 14 days without response
- Used when initial description is unclear or validation is needed
- Should not be overly difficult
- Should not require extensive code
- Typically bugs or documentation, not feature requests (due to review/maintenance cost)
- Comment should explain the blocker
- Link to blocking issue when possible
Platform and Environment Labels
Browser labels: Which browsers are affected (when applicable) OS labels (os-*): Which operating systems are affected
Customer labels (customer-*): Tracks key partners affected or Dart subteams impacted
Example: VM bug about static errors would have:
area-cfe(front end team handles static errors)customer-vm(where the error isn’t surfacing)
Team-Specific Triage: VM and IO Library
Issues witharea-vm or area-core-library + library-io are triaged weekly by the Dart VM team.
Classify the issue
Determine the type:
type-bugtype-enhancementtype-performancetype-questiontype-documentation- Other types as appropriate
Assign priority
Apply priority based on impact:
- P0: Critically impacts many users
- Someone actively working on it
- Daily updates posted
- Definitely a cherry-pick candidate
- P1: Blocks several users
- Desirable for next beta release
- Weekly updates
- Could be cherry-picked to previous stable
- P2: Important for small group or minor for many
- Desirable for next stable release
- Quarterly updates
- P3: Not critical, not actively addressed
Priorities and milestones may be adjusted based on user feedback and team bandwidth.
Assignment Policy
Dart uses a pull model for task assignment:- Most issues assigned to a team (via area label), not an individual
- When someone starts active work, they assign the issue to themselves
- Assigned issues are usually in-progress (but not always)
- Assignees may not unassign when work is paused
If an issue is assigned to a person, it’s likely being worked on, but check recent activity to confirm.
Triage Automation
The Dart SDK uses automated triage assistance:- @dart-github-bot may comment on issues as part of automation experiments
- No-response bot auto-closes
needs-infoissues after 14 days without response - Automation source: sdk_triage_bot
You can safely ignore bot comments if they’re not relevant to your work.
Queries for Triagers
Useful queries for finding issues that need attention:Best Practices
Single ownership
Every issue should have exactly one area label for clear accountability.
Consistent priorities
Priority reflects team urgency, balanced across all issues.
Regular updates
P0: daily, P1: weekly, P2: quarterly communication on progress.
Clear resolutions
Use closed-* labels and comments to explain why issues are closed.