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.

Summary

A component of the bughelper suite that generates an individual work log that can also be shared with others to assist each bug triager to develop a personal workflow and to exchange experiences with others.

Release Note

Bug triage is the process of confirming, classifying, prioritising and assigning bugs. It is crucial for good quality assurance and relies heavily on assistance from the community. Buglog helps triagers track their own progress and exchange experience with others.

Rationale

Bug triage is complicated and requires a good overview of the functioning of a wide range of software. However, we want to encourage people to join in the triaging effort at all skill levels. New bug triagers cannot be expected to know how to properly deal with each bug they come across. If they cannot find help easily they may skip over it, triage it only partially, or triage it incorrectly. In these cases time and effort is wasted. #ubuntu-bugs on IRC is helpful but does not scale well.

A personal bug triaging toolkit with a work flow system built into it could reduce the number of bugs dropped or mishandled and could serve as a learning tool for new triagers.

Use Cases

Background - bug triage work flow

For the purposes of this specification, bug triage workflow will be defined from the perspective of the individual bug triager. It is different in important ways from the workflow of the bug itself which is represented by states in Launchpad.

The purpose of the bug triage workflow is to create a comprehensive approach to dealing with any given bug so that each possible action, whether the ideal action or not, can be documented. Any given bug can then be dealt with by any triager through this system, whether that leads to a fully triaged bug, as defined by the bug's own state, or indeed no change at all. Every action that can be performed on a bug is defined and each bug has an initial state and subsequent state for that triaging session, as it relates to the individual triager. These concepts are borrowed from existing personal workflow systems such as GTD.

Design

A component of bughelper to run locally as a command line tool where a bug triager can record the work done on a bug. Local bug logs can be shared with others via the buglog bzr repo. A firefox/epiphany extension will make it possible to file log entries directly from the bug page.

Input

Record bug triaging activity with syntax on the form:

buglog --bugnumber <bugnumber> --action=<action> --comment=""

where <action> is the action performed on the bug by the triager. It should be possible to efficiently perform several actions in one command (think check boxes in a GUI form). Certain actions, like setting the status or priority can also be used to drive Launchpad directly. Examples of actions:

Other switches:

Analysis

Commands on the form:

buglog --person --category --package --time

Gathers information from your local buglog or the shared repository and from Launchpad via bughelper.

With this you could produce a list of bugs I marked as uncertain last week that someone else has subsequently edited, or bugs on the package <foo> marked as uncertain.

Browser extension

A plugin to firefox/epiphany will make buglog easier to pick up for beginners and more efficient for everyone. The buglog input fields can appear as an expandable section under the comments box(es!) on a launchad bugpage. The aggregated output will be generated from the command line in the form of a local HTML page with relevant links.

Implementation

Test/Demo Plan

We expect a gradual development as with the rest of bughelper where the triaging community provide testing along the way. Bughelper/buglog is initially intended for universe.

Outstanding Issues

Comments


CategorySpec

BugHelper/BugLog (last edited 2008-08-06 16:38:56 by localhost)