The tracker is a structured communication tool, arguably more important than unstructured communication tools such as mailing lists and chats.
While the memory of chats is short lived and that of mailing lists buried in history of archives, a tracker’s function is to keep relevant issues on top of the priorities list. A tracker helps developers keep an overview of what to do next.
The Old Tracker
Since inception Hugin has used SourceForge’s proprietary tracker. But the project has grown and the SourceForge tracker is no longer enough for our needs.
Our problem with the tracker are of qualitative and quantitative nature, and of resources/time.
We could and did address qualitative issues while still using the SourceForge tracker. Changing the settings to prevent anonymous reports enabled us to interact with the reporters and help them provide more detailed feedback and complete the reports.
This also helped reducing the quantity, although problem such as duplicate or invalid reports persisted, and the increased popularity of Hugin increased the number of incoming reports. Not a bad thing if the project has the resources to deal with the increased traffic.
In the end it was a resourcing issue. When it takes one hour just to work through a dozen reports without taking any action outside of the tracker, it is the tool that does not work.
Over the years I started a few attempts to bring the ticket count down and to prioritize the issues. It was an uphill struggle doomed to fail. The number of open tickets diminished only temporarily. More than 200 open reports coupled with the limitation of SourceForge’s tracker interface; which include a stupid default view listing all tickets including closed, invalid, stale and expired ones; made the tracker difficult to use.
So I looked for alternatives. It had to be a hosted solution. We don’t have the resources for self-hosting such critical infrastructure. It had to enable faster processing than a dozen tickets per hour. It had to provide a migration path on the way in, but also on the way out: I don’t want our data to be captive.
During an extensive research I considered multiple tools, including Google Project Hosting (wide range of supported/integrated SCM) and Github (elegant and efficient web based interface to the tracker). In the end I settled on Launchpad.
Welcome to Launchpad
There is so much good to be said about Launchpad.
Best of all is the support. The people at Canonical are responsive. You get to communicate with real people who own the issues and take pride in solving them. Exploring other tools I was on my own. At Canonical I was never far away from expert help. They set up a prototype with our real data so that we could test how life with Launchpad would be before migrating.
Next is the guarantee. Not only are there import and export tools that are maintained current and documented. As an ultimate guarantee, Launchpad is Open Source, so there will always be a solution to export data if necessary.
But the real productivity booster is the email interface. Processing a ticket becomes as easy and fast as answering to an email. No time wasted on web pages latency. Process tickets in your tested and tried environment, with fonts and colors optimized for you.
We needed a better way to manage the life cycle of a ticket and I found it. Plenty of other goodies such as tagging, voting on issues, transforming tickets into answers/FAQ, automated search for duplicates, moving tickets between projects… all rounded up the excellent impression of a mature tool that is still moving forward.
Now I needed to help our community find it. Unlike the SCM, which is a developers-only tool, the tracker has a broader constituency with disparate stakeholders, including ordinary users. A migration can only be successful if the users adopt the tool. I had no doubt about the superiority and user-friendliness of Launchpad (although a few users managed to discover rough edges at sign up and when merging the imported tickets into their profiles), but will the users sign up and use it?
Introducing the change was slightly more challenging than introducing Mercurial earlier this year. Not everybody is comfortable with change and if I was a conspiracy theorist I would swear that some resentful users were plotting to sabotage my plan.
Over time I have given them plenty of reasons to be resentful. I have little patience for a certain kind of consumers. Just calling them consumers probably offends them. I make no secret of the low esteem I have for “demanding consumer” – those that demand that others do things for them (for free, of course); those that start with the assumption that they are right and everything else must be wrong. I stick obvious facts in their face when it would be wiser to ignore them.
I have been harsh with them and I am getting back what I’ve been seeding. In some cases I don’t care. In some other cases it’s no longer fixable. In some cases the fix takes more effort than I want to invest and in some cases time will heal the rifts.
I need to learn better to ignore, and to fix/reply only what is really an impediment to moving forward.
- Let the first barrage of negative fire go past you. Don’t do like me, i.e. don’t react.
- In a second round get the key people in the project to express publicly the need for change. In our case, that “the current tracker is inadequate for our needs”.
- Invite a small representative panel of stakeholder to test. It’s like statistics: if it works for them, it will work for the population they represent at large.
- Get back to the community with the supporting findings of the representative panel and pull the change through.
I privately invited six people to the panel. Two developers, one builder, one admin, one triager, one user and myself. I carefully selected them to be representative enough of the community as a whole and including people who are hostile toward me.
In a small group it is easier to ask for people to actually do something rather than talk, and indeed they followed my request to spend a few minutes doing specific tasks and a lot of intelligent comments and critique came out. Not all comments were positive, but enough to make me feel confident that this will work well.
Pulling it Off
Pulling it off technically was easy. After the test run, Gavin at Canonical knew already what to expect. The instructions are here if you want to try. In a nutshell:
- Export your SourceForge tracker
- Run it through the import converter. You will need good pipes to the internet as the converter will scrape attachments from SourceForge and enrich the XML export file. Make sure your SourceForge tracker are world-readable when doing this.
- Freeze/block access to the SourceForge tracker
- Publish the enriched XML dump on the web
- Start a question ticket on Launchpad pointing to the file on the web
- Wait for Canonical to process your file into staging
- Test that everything is well on staging
- Repeat again on the go live day with everything going on Launchpad
- Configure your tracker on Launchpad and you’re all set
We planned to minimize the outage to the project: I produce the dump on late Sunday night on the (East Coast) and a few hours later Gavin started his working day in the UK and Monday morning I woke up to a nice surprise.
Our new bug tracker is fully operational and slowly but surely life and activity is coming into it. The challenge ahead: triage and sort the whole backlog of bugs. The work has just started.
Thank you Gavin. Thank you Canonical.