|A Better JIRA for Everyone who wants it|
|Geschrieben von: Linden Lab|
|Dienstag, den 24. August 2010 um 03:13 Uhr|
If you've been following these blogs, you've seen that we're making some major changes to how we work. In short: we're aiming to fix more bugs, faster, with more visible process. And if we're aiming to fix more bugs, we should fix our bug-tracking. But first, a quick introduction for those new to the topic.
What is the Second Life Bug-Tracker?
At Linden Lab we use the JIRA bug-tracking software from Atlassian to collect, organise and track bugs for fixing. Residents can file new bugs for our attention at jira.secondlife.com . Our engineering teams review submitted bugs and prioritise them for fixing in a process known as triage.
What kinds of bugs go into the bug-tracker?
This is a topic that confuses a lot of people, so here's a handy guide: If you've got a sudden problem that's affecting you, and you're not sure whether it's related to your account or your software, then please go to Support, not the bug-tracker. Our Support folks can help diagnose the problem and may be able to fix it quickly. If the problem is obviously a software defect that may be affecting a large number of people, it goes in the bug-tracker. So, a problem like "I can't log in and I don't know why" is a Support issue. A problem like "The 'Build' button flips upside-down whenever there's a hippo on the screen" is a bug.
That's what our bug-tracker's about. However, there's a lot about its current setup, and the way we use it, that we want to change and improve. Here are our priorities:
Triage, prioritise and fix more bugs, more effectively
Top of the list, because that's what bug-tracking's for.
A better experience for those who want to use JIRA
The current UI leaves a lot of room for improvement. We want Fast and Easy. (Fun may be a tall order, but we're open to suggestions.)
A simpler experience for those who don't
JIRA is a powerful and complex tool for those who want to go deep into the software development process. These people are in the minority. The default method of bug reporting should be far less intimidating and directly integrated into our customer support process.
More project transparency
Project teams that work in the open, such as Snowstorm, should have project management tools that those outside the Lab can follow. Everyone should be able to see the state of the current sprint, the arrangement of the project's backlog and the items that are scheduled against each upcoming release.
Better progress notification
Issue statuses have frequently not reflected the progress we're making internally. This needs to improve so that our customers can see us responding to their bug reports.
One JIRA for all
Up until now we've maintained two separate bug-trackers, external and internal, and we've imported issues between them. It's not worked that well; among other things, it's caused the issue status problem above. The two bug-trackers will be merged into one. (This won't mean that all our work will be publicly-visible; some types of issues, such as security or customer-support-related issues, need to be kept internal.)
Easier issue workflow
The workflow stages through which a bug moves should better reflect our working process. Issue statuses and resolutions will have clearer names. For example, "Needs More Info" is not a resolution; it's an intermediate state waiting on action from the reporter.
Now that we've listed our priorities, here's how we're going to address them.
Tomorrow morning we'll roll out some changes to the default workflow used in our main projects. Some status and resolution names will change, and issues which have status changes will be updated. For a full description of the changes we're making, see this wiki page. The rollout will require some downtime, which will be tracked on the Second Life status blog.
In September, we'll be migrating our JIRA setup to new hosting and upgrading to the latest version. With JIRA 4.1, we'll get an interface that's easier to read, faster to navigate, and more responsive. We'll also be installing Greenhopper, the Scrum management tool for JIRA, which open projects such as Snowstorm can use to publish backlogs and organise sprints. JIRA will no longer have a login screen separate from the main secondlife.com site; logging into one also logs you into the other. This migration is planned for September 6th and will likely take most of the day, during which the bug-tracker will be read-only; you'll be able to look at issues, but not add or change them. If all goes to plan, the new system will be live on September 7th.
There'll still be work to do after this. Migrating internal work to the new JIRA will take a while. Some workflows or other processes will likely need tweaking as we settle in. On top of that, there's the ongoing process of helping our engineering teams be more transparent and responsive in their daily work while still giving them time to get the engineering done.
Down the road, we are looking to integrate our support case system and JIRA. This integration will allow Support to associate bug-related support cases with open JIRA issues. The resident who submitted the case will be able to click through to the JIRA issue, and their case will automatically be updated as the JIRA status changes. We're also looking at ways of making bug reporting easier for everyone so that only those who want to navigate JIRA do so.
The proof of the bug-tracker, of course, is in the bug fixing. It's also in the two-way communication that enables you to see what we're working on, and tell us about other things we should be looking at. We deeply appreciate the effort you put in to filing detailed bug reports and we work to reward that effort with higher-quality software. Along the way, we want to keep all of you up-to-date on what we're doing with those reports and why we're doing it.
We thank everyone who has contributed to our bug-tracker so far; it's been incredibly valuable. You'll be hearing more from us, in many more ways, soon.