A modest proposal for fixing your bug tracker

December 28, 2010

Everyone knows that bug trackers are where bug reports go to die, at least if your project is at all large or popular. This causes various problems, the root cause of all of which can be summarized as that your bug tracker is lying to people about the true status of nominally active bug reports.

So here is a modest proposal (somewhat in the Swiftian sense) for how to fix your bug tracker. Simply introduce and automate the following policies:

  • close or expire bugs that have received no action in N months, say 4 months; such bugs can be re-opened by new activity. The assigned owner of the bug (but not the submitter) can flag such bugs as 'do not auto-close'.

  • close bugs that are still open M months after they've been submitted, say a year and a half (18 months) or after a release or two. Such bugs cannot be re-opened at all, even by the assigned owner. If the assigned owner wants to maintain a low priority 'would be nice' list, they should do so somewhere outside of your bug tracking system.

  • close bugs as 'neglected' if they have no activity by anyone but the submitter after a short period of time, say 1 month. Such bugs can only be re-opened by activity from the assigned owner or a maintainer, not by further activity from the original submitter.

(You can pick the actual numbers for the various times by mining your bug database to find how many bugs are actually solved as a function of time and the various sorts of activity. Note that 'solved' is not the same as 'marked as resolved'.)

The overall goal with this modest proposal is to have the open bugs in your bug tracker reflect issues that are likely to be worked on, instead of mostly being a graveyard of dead issues that no one will ever pay attention to regardless of what the bug's nominal state is. Thus, we expire bugs that are de facto being ignored as shown by either lack of suitable activity or simply absolute age. You can argue about absolute age, but my strong feeling is that the bug tracker that users submit to is not the right place for your wishlist.

Closing bugs that your users have submitted is going to irritate them, but it has the great virtue of being honest and you can put apologetic text in the closing message that they get. Users are not stupid and will soon work out that their bug reports are neglected and dead regardless of what the bug's official status is, and pretending otherwise is not a good idea. No one likes being lied to about what is really going on.

And after the dust settles, your maintainers will be able to actually use your bug tracker's searches to find things to work on, instead of being confronted with a wall of 'open' bugs that are anything but.

Comments on this page:

From at 2011-02-21 18:31:49:

Your proposal is absurd.

1. If a report gets submitted to the bug database, and common sense says it's just a feature addition/change request and not a bug report, then it should simply be moved to the wishlist. The original submitter can then update the report to flame the mover, and everybody can ignore him.

2. If a bug report gets submitted without instructions on how to trigger the bug, or the given instructions fail to trigger the bug, then mark it as such, and ignore it until somebody submits instructions for successfully triggering the bug. The list of such reports will grow without bound. So what? Usenet's alt.test grows without bound too.

3. If the bug obviously isn't a security vulnerability, and obviously can't cause data corruption or loss, mark it as such.

What you're left with is the list of reports of verified, triggerable-on-demand, top-priority bugs, which are either potential security vulnerabilities or potentially cause data corruption or loss. Show this list at the top of your project home page, and the current status of each item, in large bold font, and update it daily. None of your paid programmers are allowed to work on anything else while anything on this list remains unfixed.

After that, what you're left with is the list of reports of verified, triggerable-on-demand, ordinary bugs. If this is a huge wall of reports, ranging in age from ten minutes to ten years, why automatically close reports without fixing the bugs? This is your wall of shame.

A bug might get fixed by a software change made for reasons other than specifically to fix the bug. Anybody can follow the instructions in the report to try to trigger the bug in a new version of the software, and mark it as fixed or still present (or unverifiable using the reported instructions, due to changes in the software's interface). It doesn't take programming skill to do this, so you don't have to waste programmers' time on this task. The original report submitter is a good candidate for the task. Why automatically close reports without verifying that the bugs are fixed? Programmers can fix bugs which are verified to be present in a recent version of the software, and ignore the older reports until somebody verifies that the bugs are still present.

By the way, on your "how to contribute to our project" page, where you wrote "give us money" (nobody has any to give), "fix our bugs" (nobody is a programmer), and "write documentation" (nobody knows how your software works, and even if he did, he can't write well), you can add "process our bug report inbox" and "reverify old open bug reports". These tasks don't require any programming skill, solid grasp of your software's design, or writing skills; all they require are basic computer skills and and a willingness to contribute to the project. If you have unprocessed bug reports more than a week old, or bugs last verified more than a year ago, then you need to process or reverify them yourself, or hire somebody to do it, or reconsider your competence to produce quality software.

Written on 28 December 2010.
« Users don't care about security
Spam as a tax on public participation in open source projects »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Dec 28 01:40:34 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.