If you’ve ever submitted a ticket to Yorba, you probably received an email from our Redmine server some time in the last week or so. I’ve been going through each Shotwell and Geary bug one-by-one in an attempt to circumscribe the rather large, rather muddy pond they’ve grown into. Each alteration and classification I made triggered emails to the original reporter, the maintainers, commenters, and more. Thanks for your patience with us.
When I first waded into the ticket pond, Shotwell had something like 980 tickets; Geary, 390. (I didn’t take notes throughout this process so I don’t have exact figures.) Today the Shotwell pond is down to 898 tickets; Geary, 363. That’s a modest 8% reduction, and I haven’t finished the job. Most of that reduction is from closing duplicate and invalid tickets. Some were the result of making hard choices.
If you’re a maintainer of an open source project with a large and steadily growing ticket database, I’d like to share what I learned the hard way this week:
Your tickets describe a possible future. When you leave a ticket open, you’re saying, “Yep, this is something we’d like to do.” If you’re not planning to fulfill a ticket, close it. One unneeded ticket just further pollutes an already muddy and large pond and makes more work for you. A key question to ask yourself is, Does fulfilling this ticket fit into the future we see (or want) for our program?
Watch out for tickets you “kind of” or “might” want to do. If you use weasel-words to describe your interest in a ticket, that’s a red flag. Don’t open placeholder tickets either — do you want to do this or not?
Another important question is, If someone submitted a patch for this, would we land it? You don’t want to open a ticket and then reject a patch someone spent their precious weekends putting together because — whoops! — you don’t want that ugly feature after all.
You might be lukewarm about a ticket and think, “Hey, if someone does the heavy lifting for us, we’ll land their code, no problem!” Remember: if you take a patch, you’re taking responsibility for that code. Code you’re “okay” with today could be a nightmare tomorrow, and users don’t like it when features vanish.
Be bold. Wikipedia’s motto is one of the best pieces of advice given on the Internet, period. You can’t please everyone, and what’s more, you won’t, so wield an axe when triaging tickets. Jeff Atwood talks about not letting your users convince you to build a truck when you’re building a car — good advice, especially since they might actually want a car. Ticket triage is a lot like emergency room triage: each patient is important, but when there’s 980 of them, you turn away the toothaches (which, if you think about it, shouldn’t be in an emergency room). It’s tough to drop a ticket because there’s always that nagging feeling that maybe we should keep this around… Remember there are ramifications for keeping a ticket open, as I mentioned already. Be bold.
… but not too bold. One ticket I thought did not describe the right approach to a problem. A little push-back from users and a little more digging on my part revealed I’d made a false assumption. Being bold doesn’t mean not listening or skipping investigation. Don’t assume a bug’s gone away just because no one’s reported it in a while. You can’t thoroughly test every case, but at least have some justification beyond inconvenience.
Look for jumping-off points into the pond. Nine-hundred eighty tickets is a lot of tickets to slog through. I decided to break down the Shotwell tickets into categories to open up some alternate ways to divvy up the problem. To date I’ve only categorized about half of the tickets, but even that much was worth it.
The first obstacle I faced was defining “category”. My first inclination was to think of subsystems as categories. Soon I realized that associating a bazillion tickets by code location doesn’t really give you the perspective you need. I decided to concieve of our apps as solving various tasks (“workflow”) and categorize that direction. For Shotwell (a digital photo manager) I created categories like “camera” (i.e. hardware interaction), “raw”, “import”, “metadata”, “editing”, and so forth. (If this was the 90s, I’m sure “printing” would’ve made the list. Today it’s “web-sharing”.) Not only did this help my immediate problem, it’s also more intuitive for the user who has to pick one when reporting a problem — compare to a user facing such intutive choices as “async” and “cairo”. I’m still shaking out the categories thing — but again I say, be bold.
All kinds of magic happens with good categories. Duplicate tickets popped up like flowers in the snow. Inter-related tickets (potentially solved at the same time) suddenly seemed obvious. What’s more, obscured problem areas jump out. Our users are complaining about Shotwell’s duplicate detection (which prevents importing identical files) at various points in the application. Each ticket was a nit and a theory about the best way to work around it. Stepping back from them as a whole, I realized these tickets described a broader problem that we should solve as a whole, not in piece-parts. If we hacked through the tickets one-by-one, we would’ve added a lot of workarounds and unrelated features, creating code complexity and an inconsistent user experience.
One word: Need Information. A number of the tickets’ comment trails ended with asking the reporter for more information and never hearing back. Some of these queries were years old, and without that information we legitimately couldn’t move forward to fix the problem. These tickets I marked as “Need Information” and added a brief comment asking if the reporter could get back to us. Thanks to email notification some of them did respond, even years after the fact. Like not leaving open tickets you don’t plan on fixing, no reason to leave tickets open you legitimately can’t fix. I plan on reviewing the remaining Need Information tickets a few months from now. If they’re still blocked or unanswered, it may mean it’s time to close.
Stir the pond every so often. It took a chunk of time, but I feel like we now have a better grasp of the problems we’re really facing, which means getting the changes our users want to them sooner. This whole exercise took time, but I’m glad I did it. What’s more, I think it’s something that should happen at regular intervals — every six months, maybe once a year. Stirring through all the tickets is a good way to sift through the water a bit and see what’s lurking beneath the surface.
