Community Bug Reporting

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/community-bug-reporting

• Products affected: malone, ubuntu-website

LoCoTeamsUDSMVSpecs

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.

• Provide reassurance, and reduce frustration, by representing activity in a bug report (such as changes in state) more obviously and in more detail.

• Make it easier to forward a bug report upstream -- for example, by linking from relevant Launchpad pages to the upstream product's bugtracker.

• Make it more obvious when a bug is waiting for a fix from upstream, including introduction of the "Not For Us" status or an equivalent Importance level (see Bug workflow).

• When someone reports a bug, invite them to help out further by getting involved in other parts of the QA process.
• Provide more prominent feedback (such as statistics) about how your bug reports have helped Ubuntu.

We should also encourage problem reports that do not have to be processed as intensively as bug reports do: see IncreaseHardwareDatabaseParticipation and CrashReporting.

Implementation

Process

• Jono Bacon should work with LoCo team leaders to create and refine plans for LoCo bug parties.

• Daniel Holbach should investigate the possibility of holding more Hug Days.

Code

• launchpad-integration should be adjusted to include the "Report a Bug..." item in non-final versions.

• Launchpad's bug reporting form and bug page should be changed as described.

Alternative approaches

If we had enough QA volunteers, so that we could concentrate on increasing the number of bug reports, we could also set up an attractive "How to report a bug" page on ubuntu.com. This could:

• provide a walkthrough on identifying bugs, emphasizing how to reproduce them
• include anecdotes about how someone reporting a bug helped improve the software
• perhaps have specific instructions on reporting (or even fixing!) translation problems
• be very pretty, with help from the Art Team
• be localized.

We could also launch an awareness campaign, to market the fact that bug reporting is a fairly simple process and it really does help improve Ubuntu.