launchpadblog

To many people, Launchpad development looks like a black box. People asks for thing in various places (the bug tracker, the mailing lists, IRC, directly to developers, or simply wish it out loud) and then, often unexpectedly, Lauchpad will change.

We strive to work in the open, discussing changes on the development mailing list or on the bug tracker, publishing our Kanban board,  announcing stuff here on this blog, often trying to contact concerned users directly. But because Launchpad is a big project catering to the needs of many different type of users, it’s easy to miss out on some people.

So here it is, the Definitive guide on how Launchpad folks decides what to work on next!

Since the squad reorganisation, the principles used to determine what’s next will depend on whether we are looking at a maintenance squad or a feature squad.

What’s next for maintenance?

Let’s start by the easiest case: maintenance. Squads on maintenance works from the bugs in the bug tracker. And then we work on bugs starting from highest importance (Critical currently). Our triage rules explains how we determine bug importance. That’s a very verbose page that in practice means today, treat it as critical if:

• it’s a regression
• it causes an OOPS or a timeout
• creates operational issues

All the other distinctions  between High, Medium and Low at this point are  moot until we clear the backlog of such issues (see my status post to see how we are doing there). That’s not to say that we don’t fix High, Medium or Low bugs. Developers can, at their discretion, decide to work on such bugs if they happen to work in the area, or they find it related to a critical bug, or just because. But developers on maintenance will be generally found fixing critical bugs at this time.

Which one? We usually try to work on the “hot” ones. Those are the ones happening frequently or recently. But after that, it’s really up to developer’s discretion. They’ll usually pick based on their area of competence or area in which they want to acquire competence.

Once we are done with the Critical backlog, then we’ll tackle High bugs.  Again, the same kind of decision process will be used to decide which one to pick next: that is, developer’s discretion. The idea is that time on maintenance rotation should be mostly self-directed for developers.

There is another way that a bug can jump the queue, it can be escalated to Critical importance. Since it’s closely related to the stakeholders’ process, I will cover it in my next post where I’ll discuss on how we determine What’s Next? for  feature squads.

Photo by Crystal. Licence: CC BY 2.0.

This entry was posted by Francis J. Lacoste on Friday, April 29th, 2011 at 9:57 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.