Prioritization

Triaging incoming bugs is very important, but doing it beyond a certain amount of time becomes inefficient. We need to get enough bugs triaged to catch the most important ones (regressions, release critical ones) and to not run out of work for bug fixing (for both ourselves and upstreams). Beyond that point, it takes away time from bug fixing and upstream development, and thus will result in a net loss of quality.

Key points:

• Having zero NEW bugs is not the primary goal!
• Moving as many bugs to upstream is not the primary goal!
• We need to find methods how to make new bugs sort itself better by relevance and importance ("bug gravity"); no really good mechanics for that today

Primary goals:

• Maximize the number of platforms which can run Ubuntu.
• Provide features that users, customers, and we want.
• Minimize regressions in hardware support and applications.

Bug Lifecycle

(dot source)

Bug management

From the key points and primary goals from above follows the prioritization of bug management:

1. Watch out for bugs which report regressions and major breakage.
2. Work on assigned bugs in decreasing importance (debugging and fixing).
3. Spend some time on triaged bugs to see which you should assign to and fix, or forward to upstream.
4. Spend remaining time on triaging incoming bugs, on a best-effort basis.

Rules for bug management:

• Clearly separate each lifecycle stage (triaging/fixing) in workflow and mind set.
• Adjust intensity on each lifecycle stage appropriately. "Fixing" intensity gets controlled by how many assigned bugs you have, and "triaging" intensity gets controlled by separating mails about new bugs into a different mail bucket (see below)

• Keep a set of ~ 50 active bugs which are assigned to you (triaged, in progress, needsinfo).

• Unassign bugs from yourself which you know you'll never get to fixing. This will make your assigned bugs list a much more valuable tool for planning (and not staying desperate).
• Subscribe or assign bugs which you expect an answer to, so that you can have a timely dialog with the submitter, and keep the state relatively fresh in your head.
• Use states properly ("incomplete", "triaged" for bugs you don't need more information for, and "in progress" for the things you'll fix next)
• Put standard debugging procedures into the wiki, keep them up to date, and refer to them during bug triage

• Use canned responses for fast triaging

• Make use of apport package hooks and apport-collect for better bug reports.

Bug mail

Use bug mail, not just web UI lists! It's an important tool for prioritization, being responsive, and getting appropriately sized queues which you can drive to zero.

For this, you need to filter your bug mail into different buckets (mail boxes) according to their priority

1. Bugs you got subscribed to (high priority, process to zero)
2. Assigned bugs (high priority, process to zero)
3. Workflow bugs (high priority, process to zero)
4. Package bug contact, newly incoming untriaged bugs (low priority, best-effort)

The first three ones absolutely require email. The fourth (new bugs) can be handled equally well by scanning through your "new ubuntu bugs" mail folder or by visually scanning the web UI list of a package's bug list; it's a matter of preference.

Improvements

Reporting

• Discourage filing bugs directly on Launchpad web page, towards using ubuntu-bug.
• Add symptom based bug reporting and write apport hooks for it.
• Interactive bug reporting.
• More use of apport hooks.
• Add mechanism to let reporters confirm bugs on current development release (live system), and tag them accordingly.

Bug gravity

There already has been some discussion about assigning a "gravity" to a bug, which will help with prioritizing and triaging bugs. Bug gravity should depend on factors like:

• How many people are affected / number of duplicates / number of subscribers
• Marked as regression
• Number of attachments
• Length of description
• Particular tags (like apport-crash or hw-specific)
• Karma and team membership of reporter

• Release it was reported on (development release > current stable > LTS > old non-LTS stable)

Management

• Make core developers ignore untriaged bugs below a certain (pretty high) gravity. Rationale: the cost/benefit ratio is much higher for them when they use their specialist knowledge to fix bugs, than to triage incoming ones.
• Make ourselves less hesitant about assigning bugs to someone else.
• Correspondingly, make ourselves less hesitant about unassigning a bug from yourself.