Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/smart-bugreporting-tool
Created: 2006-06-08 by ZakElep
Contributors: ZakElep
Packages affected:
Summary
This specification describes a userspace tool for Ubuntu that can be used to submit bug reports to the Malone bugtracking system of Launchpad that offers full-information reporting and duplicates tracking.
Rationale
As users come and continue to use Ubuntu, it is inevitable that a certain user comes across some unanticipated behavior that may be construed as a bug. As such, it should be made possible that this user can report the behavior fully and accurately; therefore, a new tool for reporting bugs must be created that will:
- Help reduce reporting of duplicate bugs
- Help classify genuine bug reports from general and on-site support requests
- Help provide the relevant and accurate information when reporting bugs on certain types of packages (e.g. Xorg)
Use cases
- Janus observes some erratic behavior from Firefox that causes him to restart it over and over again, even when doing simple things like opening an URL. Because he is unable to open the Malone web interface, he resorts to opening the new bugreporting tool to submit a bugreport on the firefox package. The tool begins probing Janus' current Firefox configuration, including any externally-added themes and extensions, compares its findings to the Malone database, and presents a list of bugreports with similar information.
Scope
This specification aims to describe a limited version of the tool described in AutomatedProblemReports and LaunchpadSupportApp. Further feature requirements of this tool (such as supporting other bugtracking systems) will most likely require their own specifications.
This tool is not intended to replace Malone's web-based interface; rather, this tool seeks to be its complement, allowing for even users with an incapacitated Web browser to still submit bug reports from their own machine.
Design
The SmartBugReportingTool is built in three layers: a framework for interacting with the Malone bug tracking system, a control layer that helps pass information to, and from, the third and outermost layer, a simple user interface that receives the bugreport.
Bug reporting and management framework
The framework provides our model of a bug report; at the very least, it should contain information about the bugnumber, the name of the source package the bug was filed on, and the title/synopsis of the bug report. It should also offer some simple bug management facilities, like getting a short list of the latest bugs filed for a source package, the ability to set a particular severity/status for a bug, etc.
Control
The control layer sits in between the framework and UI layers, acting as the higher-level interface to the Malone system.
User Interface
The UI layer should be as simple as it gets...
Implementation
Code
Data preservation and migration
The tool should *not* touch anything that may be needed as additional information for a bug report.
Outstanding issues
- Launchpad/Malone currently does not have an XML-RPC interface (as far as I know).
- Problems with duplicate bugreports:
https://lists.ubuntu.com/archives/ubuntu-devel/2006-May/017773.html - be wary of handling
BoF agenda and discussion
Guide the user through the process of filing a bug:
- finding the affected package; if it is not possible, file an answer request
- find duplicates
- if appropriate, file a support request instead
- avoid bug reports with insufficient information
- avoid bug reports which are unrelated to Ubuntu (modified packages etc.)
- incorporate knowledge of the wiki debugging pages into this wizard
Design the knowledge base in a way that it can be incorporated and generalized into LP.
Do not hardcode the knowledge into the client side app, keep it external on people.u.c., later in LP. This avoids SRUs and unnecessary package uploads. Store it to bzr so anybody can contribute and do regular checkouts on p.u.c
Change the LP filebug page to:
- discourage using it directly, especially the general distro bugs page
- point out to use the 'Report a problem' menu item
- point out that we do not want duplicates
Workflow parts:
Help with using an application vs. "I think this behaves incorrectly" -> answers vs. bugs
- check if system is up to date, ask to update it if not
- ask about symptom categories
- [... TBD ... ]
- give reporter opportunity to subscribe to bug (if their's is a duplicate) for updates / testing but also warn about mail
Advertise:
- Promote the use of the 'Report a problem' menu item
- Fridge, Planet, etc