Wandering Thoughts archives


A modest proposal for fixing your bug tracker

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.

tech/BugzillaModestFixes written at 01:40:34; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.