In my free time, I try to help other open source projects get rid of accumulated weight from the years. At GUADEC, I told the Epiphany devs that the 3.x series (with its new design direction/vision and the gradually improving Webkit backend) would be the perfect opportunity to close massive amounts of old bug reports. Indeed, there were nearly a thousand of them open. This week-end, I closed about 150 of them. I’m not even nearly done; this will take time and patience, especially since I want to do the same thing with Empathy, which also expressed interest in a radical round of cleanup. What I’d like to convince you of is the need to reduce our “excess inventory”. Read on.
Although I’m superhuman and can shoot down hundreds of bugs with my laser eyes and uncanny searching abilities, I need some help here. If we had a concerted SWAT team of cleaners/triagers, each closing a dozen bugs every day (focusing together on one specific project at a time), we would get the whole situation under control in no time. Start small but regularly: unless you’re feeling motivated in doing batches/sprints of 50-100 in a row, start by cleaning up a dozen of them per day (and then force yourself to stop). This is a great way to contribute to GNOME if you’re a power-user who doesn’t code.
Some general principles I would like to share in this blog post:
- Move fast and avoid staying in limbo. NEEDINFO everything you’re unsure about. In six months, with a special search query, close any remaining NEEDINFO that has not been clearly answered (if the GNOME bugsquad doesn’t do it for you for free). For example, here’s a search query showing all NEEDINFO bugs that haven’t changed in the last three months.
- Be polite but firm. If you know the project’s vision, show some courage and learn to say no or “patch or it won’t happen”. If you lack experience and have doubts, ask the devs for a “yes/no” decision on a given bug. You’ll learn a lot that way.
- Do regular cleanup sessions every few months or when undergoing a significant technological or ideological change. Know the “big projects” on the roadmap and seize opportunities for cleanups (ex: old untouched bugs, core engine changes, UI redesigns and focus changes, …).
These principles stem from my personal experience, from “lean” manufacturing and the theory of constraints, from the “Getting Things Done” methodology, and from interesting articles such as Havoc Pennington’s or Joel Spolsky’s. The 2nd half of Havoc’s “Free software UI” article is mandatory reading to understand GNOME’s development philosophy of the last decade. Joel’s “Software Inventory” article has some fascinating/provocating ideas when it comes to bug tracking (but really, that’s just lean manufacturing applied to software development):
“[…] the desire never to miss any bug report leads to bug bankrupcy, where you wake up one day and discover that there are 3000 open bugs in the database, some of which are so old they may not apply any more, some of which can never be reproduced, and most of which are not even worth fixing because they’re so tiny. When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day?
[…] stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.”
This is what this blog post is all about. Reducing our excess inventory.
Towards that goal, here are some bug searching tips:
- Search for all bugs reported on [insert your deprecated technology here] (in Epiphany’s case, the Gecko/XULRunner backend). If they still affect the new backend, bump version numbers and change components as required. Otherwise, if they are not easily reproducible, kill them all.
- Search and verify all bugs older than 400 days, 800 days. Chances are they are fixed, obsolete, out of scope, duplicates, or crack (requesting features from the 80’s that 0.1% of users care about).
- Developers/maintainers: search for all unreviewed patches. Forward-port and merge yourself, or ask the reporter to do it and NEEDINFO/close in the meantime. The longer you let a patch sit there (even if it’s not 100% perfect), the harder it will be to manage and the more likely it is to be completely obsolete/wasted.
In the case of Epiphany, I added links in https://wiki.gnome.org/Epiphany/Development for sample search queries for the items above. You can adapt them for most projects.
The art of saying no
When faced with a bug report, you have three choices, especially when it comes to features:
- “Yes”. Only if it fits the project vision and you care enough about this feature to implement it yourself in the foreseeable future.
- “No for now, yes if you provide a patch”. Until then, close the bug report, or if you kinda care about the feature, confirm it, tag it “gnome-love” and possibly lower its priority.
- “No, out of scope. Sorry”. Be respectful and polite (you can’t implement everything out there due to insufficient manpower or because feature X would go against the project vision/intended UX; a canned message for that helps a lot). People will respect your decision more if they know your constraints and why you have to say no.
TL;DR: uncontrolled feature requests are vicious beasts that will eventually cloud your vision and suck your blood. Keep them at a safe distance.
Before you start flaming, keep in mind the context in which I’m saying this: long-term maintainability, a clearly defined scope, reasonable goals, a lean and agile approach, etc. I’m not saying that suggestions for enhancements/features are not valuable (they are, very much), but they need to be carefully and realistically evaluated.
Decisions need to be taken
Indecision is paralysis. Leaving a 7 years old bug report open because “nobody has made a decision” is not going to help developers attain a lean process. In bug 167592 for instance, I politely request the devs or design team to say a final yes or no, not a “maybe, I don’t know”. If we don’t decide now, we never will.
This approach may seem harsh to many (especially if you’ve never done long-term software maintenance and development), but it is the only sustainable way forward. Remember the goal: adherence to a clear vision, minimal “inventory” and achieving a lean/agile project flow.
Additional tips for bug triagers
- Retitle/rename bugs to be clearer, verbose and using common words. This makes them easier to find (preventing duplicates) and makes it easy to know what they are about at a glance.
- The “gnome-love” keyword to identify items that would be easily implemented by potential new contributors is a very important keyword.
- The “ui-review” keyword is your friend. We should start using it systematically whenever we’d like the GNOME design team to advise on a decision to be taken.
- Canned replies are very handy tools in your arsenal. Do take time to prepare some custom stock responses for your project’s particular needs, of course.
- If you’re really crazy about a particular project, you can subscribe to all of its bug mail (see the “About the -maint aliases” section on this page), after your big cleanup, to keep an eye on things in the future.
See the GNOME bugsquad page for more tips.
Which projects to work on?
We can look at the top 15 gnome modules:
- GTK+, GStreamer and Evolution are of course huge scary beasts that we cannot concern ourselves with for the time being (unless some of you want to make some special triaging hackfest for them?).
- Let’s applaud the efforts on Evolution, though: I remember it having 5000 open bug reports only a few years ago. It can be said that the situation is gradually getting under control there, though the recent de-involvement of SuSE is quite worrying.
- What remains? Core apps we use everyday: GNOME Shell, Rhythmbox (or Banshee, if you use that), Epiphany and Nautilus. In all cases, they are certainly full of old reports that are not reproducible anymore (or fixed), and in Epiphany and Nautilus’ cases, many reports that don’t fit their new vision anymore.
- However, this doesn’t give us a truly complete picture, because this report ignores feature requests. If you count the feature requests, for example, Empathy would probably show up here. It’s a good start though.
There is a big opportunity for cleanup here and we need a larger bug squad, made of users who know enough about the software they use (and the project vision) to help developers keep their sanity and direction. Talk to your friendly developers beforehand, but I’m pretty damn sure they will be delighted to have your help to bring back clarity.
Of course, this mission does not rest solely upon the shoulders of the bug squad. Developers are the best-positioned people to know when a bug is obsolete or not, and it is also your responsibility, as a software maintainer, to periodically go through “old unchanged bug reports” (on a lazy afternoon, once or twice a year, depending on your release cycle). This is what I do, for example, when a new Pitivi release comes out, and this is why the Pitivi bug tracker is a system that is kept in order, a system that I can trust and something I can actually refer to instead of something I would avoid.