Issue triage process

Jump to bottom Edit New page

Seth Ladd edited this page Sep 12, 2016 · 4 revisions

(Meta: not trying to make a laborious, or super-detailed, triage process. Use your best judgement.)

Status: draft

Objective: Developers contributing to Flutter can easily and quickly choose impactful issues.

Strategy:

Ensure each issue is actionable.
Ensure each issue is prioritized.
Close issues with the assumption we can always reopen.

When reviewing an issue, ask yourself the following questions:

Is this issue still valid?
Is it a dupe?
Is it high or low priority? (affecting partners/goals)
Do we have enough info to take action?
Do we know how to tell if it's done?
- Sometimes, issues might be valid, but are very very high level (e.g. "It's slow"). We prefer issues that we can test if we've fixed the problem.
Do we need more info?
Do we envision taking action on it in the next 6 months?

Then, make the following changes to the issue:

Engage with the customer/user, empathize with them, get more info to make the issue actionable.
Close an issue if we don't intend to work on the issue ever.
If we need more info, add "waiting for customer response" label.
- If we haven't heard back in two weeks, close the issue.
Put the issue into the correct milestone, indicating its priority.

End result:

Our engineers have a short list of impactful, actionable issues to choose from.
Customers feel heard.