Bug Metrics and Visualization for Ubuntu Engineering Teams

Registered by Brian Murray on 2011-10-19

What metrics should the defect analysts be gathering for their engineering teams? What visualizations of this data would be useful and what tool(s) should be used to create the visualizations?

Blueprint information

Status:
Started
Approver:
Kate Stewart
Priority:
High
Drafter:
Brian Murray
Direction:
Approved
Assignee:
Ubuntu Defect Analysts
Definition:
Approved
Series goal:
Accepted for precise
Implementation:
Slow progress
Milestone target:
None
Started by
Kate Stewart on 2011-11-22

Related branches

Sprints

Whiteboard

Visualization Ideas:
Pie charts of open bug statuses for packages similar to what used to exist in Launchpad itself.
Line graphs of package bug task statuses over time.
Average time to status on a per package basis.
Volume of opened bug tasks on a daily, weekly, monthly basis. Compare this volume to the historical average for this package.
Quantity of bug reports assigned to team members.
Counts of types of bugs filed about a package in particular those tagged apport-package, apport-crash and apport-bug.

Tools:
gnuplot - currently being used to generate package graphs
protovis (http://mbostock.github.com/protovis/) - javascript visualization tool

= Session notes =

Metric Ideas:
 Count of new bugs is useful for driving bugs to 0
 Count of importance over time would be useful
 Aggregation of packages into sets with above information would be useful.

Visualization Ideas:
Pie charts of open bug statuses for packages similar to what used to exist in Launchpad itself.
Line graphs of package bug task statuses over time.
Average time to first response on a per package basis.
Volume of opened bug tasks on a daily, weekly, monthly basis. Compare this volume to the historical average for this package.
Quantity of bug reports assigned to team members.
Counts of types of bugs filed about a package in particular those tagged apport-package, apport-crash and apport-bug.
Tools:
gnuplot - currently being used to generate package graphs
protovis (http://mbostock.github.com/protovis/ ) - javascript visualization tool
d3 (http://mbostock.github.com/d3/ex/ ) - javascript visualization tool (by developers of protovis)
cairo - web or gtk applications -> svg.
* should be easy to maintain
* have tooltips
* click on buttons to hide or show different aspects of the graphs
* zoom in and on dates
* pretty
* clickable links
* does it help me get bugs closed?
Ideas:
- Put the information of status.qa.ubuntu.com Ie [1] on the package status page on launchpad
 - greasemonkey to do this?
 - shows you a graph information on which package you'd need to worry(per release)
 - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric-workqueue.svg : bugs are separated by release, ie : just look at bugs tagged oneiric. feasible for the maintainers to drive the list to zero.
  - clickable graph so that you go directly to a Launchpad search
  - set up by team subscription to package. Extract information about historical status using activitly log - but hard to do.
- Looking at the type of bugs, ie: how many of those are package installation failures. (http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/packaging.html )
  - apport-package
  - package-conflict
  - fail to build from source (across all of Ubuntu)
  - etc
  - break a package down into releases using series or tags
- Have a general view of the whole set and a detailed one for each package (kind of a clickable action to display the second one)
- Statistics as part of Launchpad? So API clients would query the aggregated information, not the whole data
- Nice to have a way to differentiate between bugs with any upstream and bugs with the specific one related to the package
 - LP Bug https://bugs.launchpad.net/launchpad/+bug/829074
- Watching the upstream status of things (?)
https://launchpad.net/ubuntu/+upstreamreport on a per distroseries would be nice
- this data for engineering teams would be useful
- graphs for particular teams like indicators (being tracked by the dx/compiz team):
 - http://www.bryceharrington.org/Arsenal/Reports/indicator-applet-developers/totals-natty-workqueue.svg
 - a bit hard to read though, might be a good idea to be able to show/hide (checkbox style) a particular package , separate those by a line.
- First response time.
http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/upstream-rankings.svg
Goal is to get all off the page, can be done by forwarding upstream.
1- http://status.qa.ubuntu.com/qapkgstatus/software-center
What criteria to use to decide between tools (GNUplot, Tooltips, D3, FLOT) to use "Thunderdome" :)
- easy maintenance
- Clickon buttons to hide/show graphs, zoom in on dates
- Be taken to the data in launchpad
- Pretty
- Easy to slap in and go.
- Reconnoiter (https://labs.omniti.com/labs/reconnoiter)

Work Items for precise-alpha-2:
[brian-murray] review notes from brainstorming and propose work item priorites to defect-analysts: DONE

Work Items for precise-beta-1:
[brian-murray] determine what data to gather about package and other bug tasks: DONE
decide on priorities of data to collect TODO
[brian-murray] collect data for packages teams are subscribed to or all packages in main: TODO
[brian-murray] generate list of visualization ideas and prioritize which to tackle first: DONE
decide on priorities of graphs to generate: DONE
[brian-murray] decide on a visualization tool to use given criteria defined: DONE
[brian-murray] have mpt review sample graphs/charts for usability before settling on a tool: DONE

Work Items for precise-beta-2:
[brian-murray] create graphs / charts: DONE
[mpt] review any new graphs/charts for ease of use (summarized at bug 153199): DONE

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.