UsefulBugMetrics

Differences between revisions 5 and 6
⇤ ← Revision 5 as of 2008-06-02 18:20:58 →
Size: 4593
Editor: c-24-21-234-111
Comment: Added implementation section
← Revision 6 as of 2008-06-03 12:28:08 → ⇥
Size: 4297
Editor: cpc1-oxfd8-0-0-cust993
Comment: added use cases and implementation section
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 6: Line 5:

== Release Note ==

##This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

##It is mandatory.
Line 30: Line 23:
Currently, this information is only available via the +text interface for a bug report. Additionally, this information is not particularly useful by itself. Rather, these dates becoming more useful when considering the difference between any two dates and over a package as a whole. Subsequently, a new tool should be developed to find the differences and aggegrate the information for packages or teams. Currently, this information is only available via the +text interface for a bug report. Additionally, this information is not particularly useful by itself. Rather, these dates becoming more useful when considering the difference between any two dates and over a package as a whole. Subsequently, a new tool should be developed to find the differences and aggregate the information for packages or teams.
Line 33: Line 26:

 * The Mozilla team wants to analyse their bug workflow and throughput from New to Fixed to identify the bottlenecks where they should focus their efforts. The useful bug metrics displayed on a Mozilla summary page lets them target their effort and monitor their progress.

 * Pedro is planning a bug day to focus on the bugs that have been left in the New and Incomplete states for the longest times. The new bughelper tools let's him produce the appropriate wiki pages.
Line 44: Line 41:
##This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

=== UI Changes ===

##Should cover changes required to the UI, or specific UI that is required to implement this		  * A new lifecycle tool will be added to the bughelper suite which will also take over some of bugnumber's current fetures (leaving a simpler bughelper)
 * A range of new throughput statistics will be produced with the bug-lifecycle tool
  * '''[give examples: time in new, time to assigned, time to fixed]'''
 * Key statistics will be displayed for select packages (or rather package groups) See: [:QATeam/Specs/PackageStatus:PackageStatusPages].
Line 60: Line 56:
== Test/Demo Plan ==

##It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release.

##This need not be added or completed until the specification is nearing beta.

== Outstanding Issues ==

##This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

Summary

Identify bug statistics that will be useful to the Ubuntu team during the cycle to drive quality improvements and assist during release periods.

Rationale

The bug tracking system of Launchpad has been expanded to record some additional date information regarding bug tasks. The information currently being recored includes the following:

  • date-created (the date the bug task was created)
  • date-left-new (the date the bug task's status was first changed)
  • date-incomplete (the date the bug task's status was last set to Incomplete)
  • date-confirmed (the date the bug task's status was last set to Confirmed)
  • date-triaged (the date the bug task's status was last set to Triaged)
  • date-inprogress (the date the bug task's status was last set to In Progress)
  • date-fixcommitted (the date the bug task's status was last set to Fix Committed)
  • date-fixreleased (the date the bug task's status was last set to Fix Released)
  • date-closed (the date the bug task's status was set to a end status)
  • date-assigned (the last date the bug was assigned to someone)

Currently, this information is only available via the +text interface for a bug report. Additionally, this information is not particularly useful by itself. Rather, these dates becoming more useful when considering the difference between any two dates and over a package as a whole. Subsequently, a new tool should be developed to find the differences and aggregate the information for packages or teams.

Use Cases

  • The Mozilla team wants to analyse their bug workflow and throughput from New to Fixed to identify the bottlenecks where they should focus their efforts. The useful bug metrics displayed on a Mozilla summary page lets them target their effort and monitor their progress.
  • Pedro is planning a bug day to focus on the bugs that have been left in the New and Incomplete states for the longest times. The new bughelper tools let's him produce the appropriate wiki pages.

Assumptions

Design

Currently the bughelper suite of applications complements the bug tracking system by providing statistics regarding quantities of bug reports and specific lists of bug reports. The new bug lifecycle analysis tool should be included with this package. Additionally this should be a separate tool as bugnumbers currently has an overwhelming number of options and is primarly used to create lists of bug numbers matching specific criteria.

Implementation

  • A new lifecycle tool will be added to the bughelper suite which will also take over some of bugnumber's current fetures (leaving a simpler bughelper)
  • A range of new throughput statistics will be produced with the bug-lifecycle tool

    • [give examples: time in new, time to assigned, time to fixed]

  • Key statistics will be displayed for select packages (or rather package groups) See: [:QATeam/Specs/PackageStatus:PackageStatusPages].

Code Changes

The bughelper package relies on python-launchpad-bugs for the parsing of bug pages and accessing attributes of a bug report. Therefore python-launchpad-bugs will need to be extended to make these new bug task dates accessible.

After these new dates are accessible it will be possible to create a new application in the bughelper package to calculate the time for a change to occur for a bug task. This tool should accept any list of bugs, whether it be a package's bugs, a team's bugs, a project's bugs or a whole distribution's bugs, and calculate the time to any change.

After this functionality has been added the most useful statistics should be made publicly available for packages and teams with a substantial quantity of bug reports.

BoF agenda and discussion

CategorySpec

QATeam/Specs/UsefulBugMetrics (last edited 2008-08-06 16:36:14 by localhost)