A request tracking system

I’ve always been interested in techniques and tools that make software development more efficient. When I talk
with developers, their frustrations, if that isn’t too strong a word, often come from poor communication rather than a lack of
development tools.

• Petr: Franta, did you sort out the complaint about DNS for vrata-interplech.com?
• Franta: I don’t know. One of the technicians probably did it.
• Petr: But I need to know if anyone’s sorted it out, or at least if anyone has responded.
• Franta: I don’t know. Actually, they couldn’t have done it, because the hostmasters have to do it first.
• Petr: So is one of the hostmasters working on it?
• Franta: I don’t know. Why don’t you call them?

That exchange comes from an older article by Jakub Urbanec, Request Tracker — A Request Tracking System. The introduction asks whether your company gets requests, pleas, complaints and threats from customers at several email addresses. Do you need a system to bring some order to handling them? RT takes care of those trouble tickets. Do you know what a trouble ticket is? I recommend at least skimming the article. It’s well worth it.

I came across the article by chance through Czilla’s developer page about Bugzilla. Bugzilla
is bug-tracking software, exactly the kind of thing you turn up your nose at in the beginning and swear by later.

The difference between bug tracking and request tracking is that bugs span releases and the fix can differ by product version. Requests are relatively static. They aren’t tied to a particular version, and they may not even be intrinsically tied to the product.

Another difference is the business process. Companies usually handle a critical bug differently from a support request. Then again, some companies use Bugzilla for both bug tracking and request tracking, and it works to everyone’s satisfaction.