launchpadblog

Recently, I’ve been working with Charline, from Canonical’s design team, to talk to Launchpad’s users about how Launchpad fits into their work and what they think of new features we’re planning.

You may have seen my requests for participants on identi.ca and Twitter 🙂

In the past, someone working on a new, or improved, feature would mock-up some ideas and post them to our development mailing list. A good discussion would result but often, not always, people who use Launchpad, rather than develop it, wouldn’t see the implementation until it was available in their browsers.

Sometimes, this meant that minor, avoidable, mistakes were made. Other times it meant that somewhat eccentric workflows made it into production and dampened the impact of what was, otherwise, a cool new feature.

Improving bug subscriptions

Graham Binns has been working on some designs for an improved way to subscribe to bug reports in Launchpad. This is something we hear about a lot and also complain about ourselves: currently, Launchpad offers too little control over how much email the bug tracker sends.

We want to get this right and so we decided that this would be one of the first feature improvements that we’d put through our new mock-up testing process.

Bug subscriptions mock-up from round 1

Here’s how it worked: Graham sent me his mock-ups and I invited six Launchpad Bugs users to come and tell me what they thought. Each person had an hour, during which I asked them to imagine they were using the mocked-up pages to complete certain tasks. I recorded what they said, while Graham made notes.

This worked better than we could have hoped. Not only did we get to see what worked, what was confusing and what was just plain stupid, we got to hear about how this feature would fit into other people’s lives, giving us an even better idea of how the feature should work.

Based on what the participants said, I wrote a list of recommendations, which Graham used to refine the mock-ups.

Ciemon Dunville during round 1

The following week, another set of people came along for round two, in which pretty much the same thing happened except we were using Graham’s new mock-ups.

The interesting thing was that, by and large, these sessions were over much quicker than those of the first round. The points of confusion from the first round had been, mostly, ironed out. We had confirmation that the first round worked and the new designs were much easier to work with.

Of course, the new design is almost certainly not perfect but it’s an awful lot better than it would have been were it not for the simple process of sitting down and asking people what they thought.

You can read the full report of both rounds on the Launchpad dev wiki.

Future testing

This is something we’ll be doing a great deal more of. Right now, I’m looking at ways that we can involve a wider range of Launchpad users (i.e. not just people who happen to be able to make it to Canonical’s London offices during work hours). That could mean working remotely, doing more of this at UDS and other events, or even visiting different places specifically to test a feature or two.

If you’re interested in participating, let me know. If you want to follow the progress of this testing, join our launchpad-dev mailing list.

The Launchpad and Bazaar teams have been in Prague this week. More on what we got done in later posts. For now, here’s a photo!

The Launchpad and Bazaar teams in Prague

There are all sorts of different ways in which we in Canonical’s Launchpad team keep in touch with people who use Launchpad: informal conversations on IRC, attending Ubuntu Developer Summits, formal user research and so on.

We want to hear from as many people who use Launchpad as possible. To help get there, I’ve created a survey with five questions. Tell us what you like about Launchpad, what you don’t and what sort of work you do in Launchpad:

Take the Launchpad user survey!

I am happy to report that caching rules I put in place on many pages last week are effective. I did not want to announce that pages were faster until I could see read a week of oops reports to verify that the slow pages owned by the Launchpad registry team were no longer listed as problems. I am honestly surprised that all the slow pages I changes are not listed. I expected to make a reduction in timeouts between 50% and 80%. This looks like a 100% success. I know it is not 100%, but I think this means that milestone, series, and project pages load quicker and you are seeing fewer timeouts.

Launchpad pages now have access to memcached to store fragments of pages. Parts of pages that are costly to generate are cached for minutes or hours depending on how often the data can change. In the case of distro series pages, architecture data changes every few months so the cache rules are 6 hours. Milestone pages were a challenge to cache. Active milestones cache bugs for 10 minutes, Inactive milestones cache for 3 hours. The milestone summary of statuses and assignments cache for 1 hour. If you do not know this, you may suspect there is a bug in launchpad, or wonder if you did not update a bug as you thought. We need a mechanism to expire change when data is changed.

We are now adding cache rules to other pages to improve page load times.

Come and meet some of the Launchpad team next week in Montreal!

From around 7.30pm on Wednesday the 2nd of June, we’re going to be at Réservoir (map), which is at:

9 DuLuth Est.
Montréal
H2T 3L4

I’ll be there, along with Launchpad team leader Francis Lacoste, Launchpad Strategist Jonathan Lange and Launchpad Ombudsman Karl Fogel. Come join us for a drink and a chat.

Some of the Launchpad team will be in Brussels next week for UDS, so it’s a great opportunity to head to a bar and meet up with other Launchpad users 🙂

Come join us at Delirium Café from around 8pm on Wednesday the 12th of May. Look out for the people in Launchpad and Ubuntu t-shirts.

• What: Launchpad meet-up
• Where: Delirium Café, Impasse de la Fidélité, 4A – 1000 Brussels
• When: From around 8pm on Wednesday the 12th of May

Mail me if you have any questions or just to say you’re coming!

Many users have discovered that they could not reuse an email address that once belongs to a team. While Launchpad claimed the contact address was gone, that was not the case; it was hidden, never to be seen again. This is fixed. Launchpad does what it says. It removes the email address. The address can be re-registered if needed.

Many list moderators have noted that there are messages with no content in the moderation queue. This is because the messages had no text part, and that these are spam. Launchpad now discards messages without a text parts. You will not be asked to moderate a message that has no content. There is one caveate to this, content-less messages already in the moderation queue must be removed using the UI.

The Ubuntu packages portlet lists the most recent project packages in Ubuntu’s main archive. But there are thousands of Ubuntu packages that are not linked to a registered Launchpad project. The links are needed to forward bugs upstream, sync translations, and get the latest project code. The portlet now suggests unlinked packages.

You can help Ubuntu and the project by selecting the right package. There are many cases where the project’s name is different from the Ubuntu package, and you can search for an alternate package. You can also state that the project is not packaged in Ubuntu.

After the project is linked to an Ubuntu package, it is possible to link it to other project packages from the All packages page. You can also do this from the project’s series pages.

Update: Have a look at the Gedit Developer Plugins project’s overview page for an example.

Projects get an improved “Get Involved” portlet. This portlet provided links to create projects artefacts like bugs and branches. It was never clear though how to enable these links. Privileged users like project owners will see links to configure Launchpad applications. The portlet also call attention to applications that are not configured.

The first use of the not configured state is the project branch. Contributors cannot submit code if Launchpad does not know the series branch, and most importantly, communities like Ubuntu need access to the project’s focus of development. The new Configure (project|series) branch form allows you to setup an code import and link the branch to the series.

A few links to Launchpad related posts from the past month or so:

• Fixing the bug tracker widget: Curtis Hovey looks at what’s wrong with the way you set a project’s external bug tracker, in Launchpad.
• No project is an island: Curtis again, “I think the best summary of what Launchpad does is that it hosts open source communities.”
• Canonical pays to upgrade Gnome’s Bugzilla: “…the makers of Launchpad paid for improvements to Bugzilla, a competing product—not to mention that Ubuntu’s competitors will benefit from improvements to GNOME. As [Kiko] notes, Canonical views this as ‘bridging the gap’ from Ubuntu to upstream.”
• Microsoft developer Garret Serack announces The Common Opensource Application Publishing Platform (CoApp): “CoApp aims to create a vibrant Open Source ecosystem on Windows by providing the technologies needed to build a complete community-driven Package Management System, along with tools to enable developers to take advantage of features of the Windows platform.” And it’s hosted on Launchpad.
• Being the Launchpad Release Manager: Deryck, the Launchpad Bugs team lead, talks about managing a Launchpad release and asks if it makes sense to talk about website releases.