share their experience to fix it. The solution to this problem is to identify how the flow of conversation and collaboration happens between these different bug reports and to optimize it. Fortunately, software can address these issues. Launchpad, the web service that Ubuntu uses as a bug tracker, already had the ability to link bugs, whether they’re in the same tracker or a different one. When Erica filed her bug, she or someone else could connect her bug to an existing bug in an upstream bug tracker. It works like this: 1. If the developer knows the bug is an upstream bug but does not know which bug it is in the upstream bug tracker, he can add an upstream task to the bug report. This upstream task indicates that the bug should be linked to an upstream bug when it is found. 2. If the developer knows the bug in the upstream bug tracker matches the Ubuntu bug, he can link the two bugs. This involves finding the Ubuntu bug and using the Link feature in Launchpad to enter the URL of the upstream bug. When a bug is linked, any changes made to the upstream bug are synchronized in Launchpad and vice versa. This feature connects the two separate conversations.
Getting to know the problem Although this is a hugely useful and valuable feature, we got the impression that not enough bugs were getting linked. The problem that I wanted my team to solve was to explore why these bugs were not being linked and help to increase the linkages. Although we had a hunch that not that many people were linking bugs, we really had no idea. We had no concrete statistics to back up our assumptions. Our first task was to learn more about the problem. To do this we produced a tool called the Ubuntu Upstream Report (https://launchpad.net/ ubuntu/+upstreamreport). The report mined the Launchpad bug tracker to show the top 100 upstreams shipped in Ubuntu ordered by the greatest number of open bugs. We knew that these 100 upstreams were likely to be the largest and most significant projects: more bugs in the open source world typically means larger projects with more users using the software and therefore filing more bugs. For each upstream in the report, we showed which bugs were open, which had been triaged to determine they were actually bugs, which were known to be upstream bugs (marked as upstream tasks), and which had linkages associated with those tasks. The differences between the numbers generated interesting conclusions. As an example, if a project had a significant difference between the number of open bugs and the number of triaged bugs, we knew which projects needed more help with bug triage. A key conclusion that we discovered was the difference in many projects between the upstream tasks and linked bugs numbers. As an example, one project had 229 bugs with upstream tasks but only 101 of those bugs had upstream links. This left a total of 128 bugs that were known to be upstream bugs that didn’t have linkages. This told us that the project was not linking bugs
SUPPORTING WORKFLOW WITH TOOLS
127