launchpad developmentLaunchpad blueprint: other-q-defects-dashboard
To make Ubuntu development more efficient, Launchpad’s distribution series Bugs page should be 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, error reports, translations, and so on.
Rationale
A bug tracker exists to help developers make best use of their time. For someone working on an OS release, this falls into three broad areas:
- choosing the most effective thing to work on next
- choosing the most effective things for people who work for you to work on
- identifying improvable processes.
Attempting to make these tasks easier, Ubuntu developers have produced dozens of “reports” on various release statistics in the past (examples 1, 2, 3, 4, 5, 6, 7). But these have been spread over many different Web sites, have often gone 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 outside-of-Launchpad data like error rates.
Initial design
Any URL of the form 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 bugs closed each day (fixed, declined, or marked as duplicates), for motivation.
The graph should start from the date the series opened, and extend to the date of the latest registered milestone. (This might be a point release, or even the EOL for the series.) All registered milestones should be shown as dated 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 Throughput graph for nominated bugs — showing how quickly they change between the different bug statuses after being nominated. 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, and bugs with verification needed.
In the “Things you can do” and “Neglected bugs” sections, the whole of each row should be clickable to expand it, revealing the top six bugs in that category followed by a “More…” link. But the row should otherwise act as a normal hyperlink to the full listing: for example, Ctrl+clicking should work to open it in a new window/tab, and right-clicking to copy the listing URL.
The purpose of the “Things you can do” section is to help you choose what to work on next. “Apply patches/branches” should list unassigned open bugs with either a patch attached or a branch linked. “Apply fixes from elsewhere” should list unassigned open bugs recorded as being fixed upstream or in another OS. “Test whether bugs are reproducible in Quantal” should list unconfirmed (“New”) bugs. And “Test/report bugs upstream” should list bugs not yet filed (in open or closed state) against upstream, or filed but missing a bug watch.
Finally, the purpose of the “Neglected bugs” section is to help release managers realize which — and what kinds of — bugs are being neglected, so they can act to fix the problem.
Future work
The defects dashboard could contain many other things. The initial scope is intentionally very small, because the more the dashboard contains, the less likely it will be implemented at all.
Implementation
Launchpad’s “Maintenance costs” policy requires that a change to Launchpad does not increase the number of lines of code, unless (a) it is a step on a path to reducing LOC, (b) it will reduce non-code costs, (c) it is moving code to “a smaller, leaner and more focused sub-project”.
These three exceptions are all true, if you consider Ubuntu as a whole rather than Launchpad as an island. (a) The dashboard will reduce the total number of lines of code devoted to release reports, by replacing redundant reports that are currently outside of Launchpad. (b) It will reduce non-code costs for Ubuntu development, by making release management and QA more efficient. And (c) the dashboard will move, to a single focused page, information that was previously spread over multiple Web sites.
