To make Ubuntu development more efficient, Launchpad’s distribution series Bugs page should default to a defects dashboard that graphs nominated bugs by status over time, shows throughput in dealing with bugs, links to important tags, lists things you can do, and highlights neglected bugs. Once this is implemented for bugs, it can be extended to a release dashboard that gives a higher-level view of bugs, builds, errors, translations, and so on.

Rationale

A bug tracker exists to help developers make best use of their time. For a someone working on an OS release, this falls into three broad areas:

1. choosing the most effective thing to work on
2. choosing the most effective things for people who work for you to work on
3. identifying improvable processes.

Attempting to make these tasks easier, Ubuntu developers have produced dozens of “reports” in the past (examples 1, 2, 3, 4, 5, 6). But these were spread over different Web sites, often went unnoticed, and sometimes stopped working altogether when Launchpad’s API changed or scripts stopped running. We can avoid all these problems by insisting on building any dashboards into Launchpad itself. (As a bonus, this will help derivatives too, not just Ubuntu.)

Many things to work on, and processes to improve, do not involve bugs specifically, or even information from Launchpad at all. But by starting with a defects dashboard, using only bug data already in Launchpad, we are more likely to succeed in producing something at all. Later we can extend the work to a general release dashboard, including things like build failures, archive coherency, and error tracking.

Initial design

By default, bugs.launchpad.net/distribution/series should show a “Dashboard” tab for the series. A “List” tab should be a link to /+bugs, the traditional bug listing. And any search should replace the dashboard with search results.

First in the dashboard should be a graph of open nominated bugs over time. This serves three main purposes:

• showing whether the release is on track, or whether priorities need changing (declining nominations, reallocating engineers, moving the release date);
• showing whether any states are getting out of control and need attention (for example, increasing unconfirmed bug reports);
• showing the rate of work each day (fixing or declining bugs), for motivation.

The graph should start from the date the series opened, and extend to the date of the latest registered milestone. All registered milestones should be shown and dated as marker lines. By default the graph should color-code by bug status, with radio buttons to switch to color-coding by importance.

In the graph legend, each count should be a hyperlink.

Next should be a graph of throughput for dealing with bugs once nominated — showing how quickly they change between the different bug statuses. The purpose of this graph is to identify bottlenecks in the release management process (for example, bugs spending too long In Progress). This graph should use the same colors for bug statuses, and for “Fixed”, “Declined”, and “Duplicates”, as the main graph does.

The “Tags” section should list the most common tags in order of frequency, as it does now, but should responsively use as many columns as will fit in the viewport width. The purpose of this section is to provide easy links to important listings such as bugs found during ISO testing, hardware certification failures, regressions, or bugs with verification needed.

Related work

• LEP/Dashboards

• Wishes/PersonalDashboard