RT: Request Tracker trouble ticket system
It's hard to have great weird ideas when you're busy closing trouble tickets.
We're using RT from Best Practical as a trouble ticketing system. I've heard basically good things about it from a few people who use it, it seems to be quite stable, and there's an active developer base for it.
RT can feed out results of stored queries as RSS feeds, so that you can track things in your news aggregator. It's a little bit awkward unless you have something like NetNewsWire, though, since they use cookie-based authentication. Chris Dent wrote a tiny app that caches cookies, then uses the rss-from-a-program feature inside NetNewsWire to pull things down.
It's a bit of a challenge to sort through trouble queues, as anyone knows who has ever had too much to do. Do you do the easy stuff right away, even though it's not that important, just so that it gets in and out of the queue quickly? Do you always tackle the hard stuff first? When do you mark something as closed, even though there's still a bit more work you can do on it? There's a certain discipline akin to managing throughput through an industrial process, like pumping sludge through a treatment plant. All the while, you need to keep something resembling like a human voice on things so that people don't get the sense that they're talking to a disembodied computer.
A really good ticketing system would mostly get out of your way in the process. RT is so "powerful" that sometimes it takes 5x longer to report on the solution of a problem than it does to actually do the fix.


If you do a google search for "Asterisk Request Tracker" you'll get back information about integrating the Asterisk VOIP and call handling platform (free, runs on Linux) with Request Tracker. Alas, the details of the solution are on web sites that are temporarily unavailable. Thanks to the anonymous google-queryer who reminded me of that - if I find details I'll do a new posting.
Posted by: Edward Vielmetti | December 02, 2004 at 09:36 PM