launchpadblog

Nothing breaks my heart quite like a request to make a project private–make it invisible to everyone except to the people the project trusts. I am utterly crushed when someone who works for Canonical or on Launchpad asks for one. I have been planning this feature for more than two years, and the Purple squad has been working on it for 13 months. I blog about this, I send emails about this, I present reports on this, but the people who most need private projects don’t know what the Purple squad is doing. I think the problem here is that Launchpad squads no longer use Launchpad to plan and execute work. There is no place for any interested party to see what the goals of Disclosure is and gauge how we are progressing.

I present my first draft of a report that states the simple goals of that the Disclosure feature wants to achieve . The report provides some summaries of the work that allows anyone to see what the Purple squad is doing, recently done, and will do next. There is also some analysis that provides insight into the amount of work remaining. This report complements the Purple squad’s kanban board. While kanban is excellent for tracking branches of code and technical tasks, the level of detail is unsuitable for non-Launchpad developers. The kanban board is also only accessible to a small number of people. I want a report that anyone interested in private projects or managing the disclosure of private information can see and understand. Mostly, I want everyone to see that the Purple squad is delivering valuable features and know when we will be done.

I based the report on the intended reporting UI for Launchpad series and milestones. I really miss using series and milestones to plan releases. For every milestone, I wrote our goals in the summary, and targeted bugs to the milestone. Though we abandoned the analytics because of performance concerns, I could reliably judge  the contributors’ velocity, and see when I needed to retarget work to another milestone because the remaining effort exceeded the milestone’s work capacity. Though I didn’t provide a burn down chart of the work, I could sort the milestone to see the colour change. I could confidently see and predict 3 months of work.

This report replaces the canvas-based chart I planned for series and milestones with a YUI 3 chart. The listing of bugs are split into categories so that I can focus on scheduling or provide Diogo with a list of bugs that need exploratory testing. Though this report thinks it is talking to Launchpad, it is actually using JSON for the 500+ bugs that I pulled using a trivial Launchpad API script. Since the data is cheap to retrieve, I can load the chart multiple times, each looking a different set of bug tags so that I can see specific themes of work.

The report shows that there is more than 60 days of work to complete the features needed by private projects. The Orange squad will work on private projects while the Purple squad finishes the prerequisites.

Over several months, we have released many small improvements to the project series, milestone, and releases pages to make release planning easier in Launchpad. Well, not all the changes were small. Some were subtly disruptive. Here is an explanation if what happened that I hope will give you ideas of how we can make more improvements.

In November of 2008, Barry Warsaw and myself sprinted with Martin Albisetti to plan the Registry features for Launchpad 3.0. Martin was very insistent that we make series management easier for developers. He proposed a timeline to visualise the past and future of lines of development. You can see the first draft of this feature on the project page now. We are adding it to the series page and the series timeline page (which has always claimed to be a timeline even though it did not present one) for the next release.

I realised during the discussion of how to make the timeline that I did not like the series page, or the milestone and release pages. They looked like historical documents, they were not tools that helped me plan releases.

The immediate problem was that milestones were disconnect from releases, the former must lead to the latter. Even if your project does not use milestones for planning, the information of the milestone is implicit in the release. The release is a device for holding the release notes and the release files, all the other information is the milestone. We made the milestone the primary artefact of the series…milestones may existing long before a release, and not every milestone leads to a release. Creating a release is really an event at the conclusion of the active life of a milestone. We still permit projects to create a release directly from the series page, but you must select the milestone that is being released. If the milestone does not exist, you can create it at that moment. There is no additional work in this process; the milestone fields are the same fields that the release duplicated.

By creating a single page to present the milestone and its release, it became easy to see the planned and achieved work. The page initially shows all the bugs and blueprints targeted for the milestone and you can see the state of each one. When the release is created, the milestone is deactivated (bugs and blueprints cannot be targeted to it any more) and the release note and files are displayed.

The series page now shows the milestone and releases for the series. You can see a summary of all the work targeted to the milestone. You can see which milestones have releases. Developers can see the location of bazaar branch where they can make contributions. Distro packages are listed for distro maintainers and curious users. Adding a milestone to a series is very easy, adding many is easy too.

These pages make my job easier. They are now tools. They could be better though. Martin pressed me into adding the counts of bugs and blueprints in each status for each milestone to the series page. I can see now that they are very useful. I want to add this same summary information to the milestone page. I want to see a burndown chart on the milestone page. A burndown chart is a tool that compares the remaining work in a milestone to an ideal line to meet the milestone estimated release date. I want to know when progress is slow so that I can take action to meet my series’ schedule.

I decided to use the title of “release manager” for the driver assigned to a series. This is a UI improvement. I am a release manager, but I cannot create milestones or releases. Nor can I update these if I want to make a correction. I cannot effectively plan, nor can I create the objective of most of my plans. This sucks. I want to give the release manager the power to accomplish his objectives.

Please give this tools a try. Your feedback is appreciated, as too are your ideas for new features that make release planning easier.