Ubuntu Wiki

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: buglog

• Packages affected: bughelper

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

• Henrik is a non-developer who has some experience with bug triage, but still has much to learn. He often sees bugs that he doesn't know how to triage further and has to either seek help or skip the bug. He finds the former to disrupt his work flow and the latter is inefficient in a global perspective. With buglog he can process a larger number of bugs in a day, without worrying about making mistakes. By looking back on bugs that he left for those with more experience he learns new triaging techniques.
• Sebastien is an Ubuntu developer and very experienced with bug triage. He would like an efficient way of sharing his experience with others so that they in turn can be more productive triagers. With buglog he is able to focus his time on the bugs that are less obvious.

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:

• Set state to <state> and Set importance to <importance> - Same as the Launchpad states. Interaction with LP would be useful to automate the recording of this change.

• Changed package - Record linking a bug to a package, or the failure to do so. e.g. 1 == 'This is the right package', 2 == 'I think this is the right package' or 3 == 'I have no idea, please help'

• Moved upstream - Created an upstream task (1), Filed an upstream bug (2), did both (3)

Other switches:

• Unable to read log - a log is available, but the triager is not experienced enough to read it

• Corrected previous triaging error - The bug has been incorrectly triaged, now corrected

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.

• --person is 'myself' by default, but could also be 'all', a given individual or team.

• --category states used by different triagers, such as 'what package?' or 'fixed mistake'

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

• buglog code is available in https://code.launchpad.net/~bughelper-dev/buglog/main

  • daniel@lovegood:~/bzr/buglog$ ./buglog-tool --help
    Usage: buglog-tool [options]
    
    Options:
      --version             show program's version number and exit
      -h, --help            show this help message and exit
      --no-idea=NO_IDEA     bug number and comment
      --ok=OK               bug number and comment
      --needs-confirmation=NEEDS_CONFIRMATION
                            bug number and comment
      --push                push changes to Launchpad
    daniel@lovegood:~/bzr/buglog$ 

• a shared data repository is located here: https://launchpad.net/buglog-data/

• The implementation plan looks as follows:

  • Let buglog-tool commit data about the person, the action, the bug, the triage state, etc. in XML format to a bzr tree. [DONE].

  • Modify epiphany-extensions and greasemonkey to respect and consider globally installed greasemonkey scripts. [Patches written and pending upstream]. (1 2)

  • Write greasemonkey script that adds additional HTML form controls to bug pages, that do a HTTP POST to a .cgi script that will call buglog-tool to commit those values after some sanity checking to the bzr tree. [Work started].

  • Add statistical and summary functions to buglog-tool. [TODO]

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