Tracking bugs

Work continues to be very busy. Partly this is because we’ve been settled in our new premises for a little while now and people are bringing up all sorts of issues that they had previously kept quiet about; also, now being A Team Of One, rather than One Of A Team Of Two doesn’t help. I was hoping to be able to provide a link to the job advert for PerfDave‘s replacement today, but the university admin doesn’t appear to have progressed that far yet.

As a result of the huge number of things to do, I’ve decided to add to the existing issue-tracking system we have, Request Tracker (RT), in order to

• keep a proper track on things, and
• make my tasks transparent to staff (which has the side-effect of giving them an appreciation of my high workload!)

What I’ve actually done is introduce Bugzilla into the mix. Typically, this is used for tracking bugs in software, but it lends itself to any situation where there are a large number of issues having dependencies on one another and having different priorities and severities. I’m now using RT and Bugzilla like this:

• Request Tracker will be used literally for tracking staff requests: non-trivial things that I am asked about, questions about “how to …?” or whatever. These requests from staff, and the email correspondence arising from it, are all recorded in the RT system. RT has been in continuous use since I first installed it in 2001 and has clocked up approximately 1800 ‘tickets’ since then, almost all of them being processed by me! Since some of the issues in RT tickets may be sensitive or perhaps personal, the content of other people’s tickets is not available to end users.
• Bugzilla will be used for keeping track of ‘bugs’, used in the loosest sense to mean “things that are wrong that need to be fixed”. In some cases, these may relate directly to particular RT tickets (for example if someone uncovers a problem with a server or system that needs to be fixed – rather than a misunderstanding on the user’s part); in other cases, many RT tickets may relate to the same ‘bug’ (for example, a number of people may experience a symptom which is all related to the same underlying issue) and so each ticket can reference the same bug and everyone who reported a similar problem will be able to see the progress of the ‘fix’. Sometimes, a ‘bug’ has no direct relationship to an RT ticket at all, for instance infrastructure issues and problems I notice myself: these are entered into the bug-tracking system and are visible to any staff who care to follow them. I used to deal with the latter issue by raising an RT ticket to myself(!), but that’s always struck me as The Wrong Way To Do It and also unnecessarily conceals information from staff about what’s going on. The other point of having an ‘open’ bug tracker is that any member of staff can add comments to any outstanding issue, which might be helpful, although in practice only a handful of technical staff will be likely to do this.

Both RT and Bugzilla are free, open-source tools and are both excellent pieces of software. I think it’s a good decision introducing Bugzilla, particularly. I plan to make various categories of bug listings easily available to all staff, so that they can view (say) “all outstanding bugs”, “all outstanding ‘wishlist’ items” (bugs categorised as ‘wishlist’ are not actual problems, but requests for improvements or enhancements to the existing way of doing things) and so on. I am hoping that by making the bug-tracking database visible to all staff it will hammer home the point that I really am busy and that when I say Don’t Phone Me And Don’t Come To My Office, Please Send Me An Email it’s because I’m trying to avoid distractions and stay efficient.