BugWorkflow

Revision 5 as of 2009-06-05 22:40:41

Clear message

Summary

Goal

Maximize the amount of bug fixing that occurs per unit time invested in bugs management by desktop team engineers.

Rationale

The current situation is:

  • Many desktop team engineers are swamped with bug reports. That is, there are more bug reports in their areas of responsibility than they can reasonably address.
  • The desktop team has a history of addressing each and every bug report.
  • Bug reports are a vital source of feedback regarding the quality of the product.
  • Users have an expectation that a bug report will result in a timely fix, and may even expect support via their bug report.

The goal state is:

  • Desktop team engineers can meet their obligations regarding bug triaging.
  • Desktop engineers can spend more time fixing bugs when appropriate.
  • End users have appropriate expectations regarding the impact of their bug reports.

Approach

A multi-pronged approach is being used to make progress towards this goal state:

  1. The launchpad team is changing launchpad so that it helps users use ubuntu-bugs to report bugs. This should result in fewer but better quality bug reports.
  2. pitti is enhancing ubuntu-bugs to be "symptom based" (see ). This should result in even better bug reports.
  3. Work with the launchpad team to add verbiage to launchpad that could help set the users' expectations regarding bug reports.
  4. The launchpad team will add an "expired" state to older bugs, reducing the noise in the system.
  5. The desktop team engineers will limit bugs assigned to them to bugs that are targeted to be fixed in the current cycle.
  6. Craft a tool that dramatically speeds up the bug triaging process.
  7. Craft a tool that "watches" for bugs in new uploads, allowing engineers to respond to regressions more quickly.

User stories

End User

A user encounters a bug in program Foo. Based on previous experience they go to launchpad.net to log the bug. When click the link to add a bug, they are shown instructions to use ubuntu-bugs. They run ubuntu-bugs which gathers data relevant to their symptoms and logs the bug for them. When the bug is logged they see a message telling them that the bug will be triaged, but may not be fixed, and also tells them where to go for support.

Triaging Tool

seb128 starts work in the morning. He fires up an app that chugs away on launchpad loading bugs into a list in the areas of GNOME that he works on. He gets some coffee and works on email. When the list is finished loading, he is able to look over the list and select bugs in batches. He can click buttons to set the bugs into different states, such needs info, won't fix, etc.... When he is done, he knows that he has triaged all the new bugs in his area.

Doing an Upload

asac uploads a firefox security fix. An hour later he starts getting bug mails about a regression some users experience. The mails are marked as being related to his recent upload (reason=upload watch). He triages the bugs. He gets similar bug reports for the next 48 hours. After 48 hours, the emails stop coming related to the upload, though bug mails are sent in the normal fashion.

Assumptions

Design

Implementation

Triaging Tool

This will likely be added to or derived from the pm-dashboard code:

This will require:

  1. a way to define a set of packages to query for bugs to triage
  2. A list view with enough information for assessing the impact of the bug
  3. A way to quickly select batches of bugs
  4. A needs info button that can edit bugs in bulk to need info
  5. A needs to be worked on button
  6. A would be nice to get worked on button

Needs Info

Clicking this button would set the status to "needs info". It would inject boiler plate "needs info" text into the comments.

Should be Worked On

Will set the bug priority to High and the bug status to Triaged, and will assign to the canonical-desktop-team.

Nice to Have

Will set the bug priority to Medium. Will not assign the bug. Will set the bug to triaged. Will add a comment that the canonical-desktop-team will not work on it, but would welcome help on the bug.

UI Changes

  • pm-dashboard my need a different list view that includes description info
  • A way to multi-select bugs will need to be added to the list view
  • buttons for triaging will need to be added
  • perhaps a way to change boiler plate on the fly will be needed

Code Changes

  • new list view with more bug info and selectability
  • new tab pane with triaging buttons
  • ability to update bugs

Upload Watch

There is no UI for this per se. This is essentially a cron job that will run on rookery, and detect recent uploads, and direct bug mail appropriately. The key idea here is that after doing an upload, engineers must monitor their email for regressions related to the uploaded packages, and must sort those bug mails out from the bulk of other bug mails. This system will separate bug mails out as potential regressions if they are related to recently uploaded packages.

Code Changes

  1. a cron job that detects recently uploads
  2. a way to create a special subscription to bugs on packages related to those uploads
  3. a way to change the headers for those bug mails so that engineers can sort them seperately
  4. a way to unsubscribe after a set period of time, when the upload is no longer "hot"

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec