Issue Triaging Process

How Dart SDK issues are triaged, labeled, and prioritized

The Dart SDK repository contains tools and libraries maintained by multiple sub-teams. Effective triaging ensures issues reach the right team with appropriate priority labels.

Triage Workflow

1. Find untriaged issues

   Use the SDK triage query to find issues without area labels.

2. 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-meta and assign to someone who can coordinate
3. Add library label for core libraries

   For area-core-library issues, also add the specific library-* label:

   • library-io
   • library-async
   • library-core
   • etc.
4. Add type label (optional)

   If obviously a bug or enhancement, add:

   • type-bug
   • type-enhancement
   • type-documentation
   • type-performance
   • Other type labels as appropriate
5. Transfer if needed

   Does the issue belong in another dart-lang repository?

   • Use the “Transfer issue” link to move it to the correct repo

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.

Issues with no area label or multiple area labels often fall through the cracks. Single ownership ensures accountability.

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

contributions-welcome: Vetted as legitimate and suitable for external contributors

• Should not be overly difficult
• Should not require extensive code
• Typically bugs or documentation, not feature requests (due to review/maintenance cost)

blocked: Unable to make progress due to external dependency

• 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

These labels indicate known affected platforms but don’t guarantee other platforms are unaffected. Absence may mean “not investigated” rather than “not 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 with area-vm or area-core-library + library-io are triaged weekly by the Dart VM team.

1. Classify the issue

   Determine the type:

   • type-bug
   • type-enhancement
   • type-performance
   • type-question
   • type-documentation
   • Other types as appropriate
2. Request info if needed

   Add needs-info label and comment asking for specific information.

3. 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
4. Assign developer (P0-P2 only)

   For P0-P2 issues, assign to a specific developer.

5. Set milestone and mark triaged

   • Assign milestone based on priority
   • Add triaged label to indicate the issue has been reviewed

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-info issues 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:

• Issues with no area
• Issues with no priority
• Issues with no type
• Meta-issues with no assignee

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.