Summary

To increase the effectiveness of Ubuntu's bugtracking, we should get ForumAmbassadors to encourage forum participants in creating useful bug reports; establish "bug parties" for LoCo teams and user groups to help out with QA; provide a "Report a Bug..." menu item for programs in Ubuntu alphas and betas; and make various changes to Launchpad's bug reporting and report pages to encourage useful bug reports and other QA work.

Rationale

Effective bug reporting and tracking is central to the success of software projects. Daniel Holbach expressed concern that Ubuntu does not have enough QA volunteers to keep up with reported bugs. So encouraging more bug reporters, without a corresponding increase in QA volunteers, would likely result in newly-reported bugs going for weeks or months without a response, which would give the overall bugtracking process a bad reputation.

Jono Bacon and Simon Law agreed that we should, therefore, concentrate on training new QA volunteers before taking any major steps to encourage new bug reporters. However, we should still make it easier to report bugs for those people whose bug reports are already likely to be immediately useful.

Scope

We should target three groups of people: forum participants, LoCo team members, and the sort of enthusiasts who install pre-release versions.

Out of scope are the establishment of a testing "group", standardized test scripts, or a testing checklist; these are all good ideas, but a different topic.

Design

Forum participants

Many forum threads are created for troubleshooting something that turns out to be a bug, and sometimes these bugs don't get reported. (Simon Law estimates that 5~10% of bug reports currently originate in the forums.)

To get these bugs reported, the ForumAmbassadors "job description" should include watching for bug-related forum threads, and encouraging the originator to report a bug containing relevant debugging information (or report it themselves, if the originator doesn't want to and no further information is required). These bug reports should link back to the original forum thread, as it often contains useful debugging information. If this system works, forum contributors eventually should be encouraging each other to report bugs, without prompting by the forum ambassadors.

We considered having a forum subsection dedicated to reporting/triaging bugs, but UbuntuDemon disagreed with that idea. Often people posting about a problem will not initially realize that it is a bug. There may, however, be a forum section for forum users to contact forum ambassadors, and this may include asking for help in reporting a bug.

LoCo team members

LoCo teams and user groups should be encouraged to get involved with bug tracking. One way to do this is to organize "bug parties", where team members get together to eat snacks and to clean up bug reports (taking care not to confuse the two). These would be analogous to Debian's Bug Squashing Parties.

Activities at bug parties could include:

Resuscitating initially-useless bug reports, by asking the reporter for the necessary information.

Finding and reporting (or fixing) translation bugs, for LoCos in countries where any language other than US English is widely used.

Collaborating on reporting bugs, between English non-writers who experience bugs and English writers who can report them.

Passing around live CDs (or VM images?) of the latest development alpha/beta, so people can test all their hardware and report bugs if necessary.

Enthusiasts

Most Ubuntu users use release versions. For bug reporting purposes, these are less useful than the development version, for two reasons:

a bug in the release version may have been fixed in the development version

it is better for a bug to be reported and fixed before a release than after it.

Therefore we should encourage those using the development version to report bugs. Ubuntu's Launchpad integration should be altered so that Help menus include a "Report a Bug..." item during the development process, with this item should disappear shortly before the final release. (Perhaps in future those using final releases should be provided with easy access to the support tracker).

The Hug Days programme should also be continued, and expanded if possible, to get more enthusiasts involved in QA work.

Everyone

Some changes should be made to Launchpad to make bug reporting and tracking more effective.

On the bug reporting page, ask for the version number of the reporter's software. (Simon Law says this is his most common initial question on new bug reports.)

Manage expectations about bug reports (bug 37926), by providing an indication (either during, or immediately after, the bug is reported) of how likely it is to be fixed. For example:

a bug reported about an Ubuntu 6.06 Universe package probably won't be fixed

even a bad bug on a Restricted package can't be fixed.

Let developers/packagers specify what is "on their plate" right now.

Technically this is handled by the "In Progress" state, but maybe this can be made easier to set.