[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ticket systems

Dan MacNeil wrote:

Right now our "ticket" system is an email alias to our small group and a policy that we CC the alias on replies.

For current volume this is fine. Things fall through the cracks, but only rarely. However, at our current growth, it is not hard to extrapolate to a problematic future.

I'm curious as to how people use ticket systems and their bad experiences with ticket systems. "How" and "why" are more useful right now than "what". I'm not especially interested in "request-tracker rocks!" or "No! otrs rocks more!"

I've heard people say that it is nice to have system created tickets, (naigos reports webserver down) or to have master tickets. (10 people complain about webserver down, close master ticket and close linked tickets)

I'm also not sure of where the line between a ticket system, project system and a bug tracking system lies or should lie.

I've worked places where people game the system. A good evaluation comes from closing lots of tickets, so people are motivated to close tickets rather than solve problems. There are also some disincentives to put hard-to-solve problems in the ticket system....

RequestTracker from www.bestpractical.com works well, and there are official Debian packages for it, but they're behind the current releases by quite a bit now if you're on Sarge.

request-tracker3.4 package.

This is the "RT" everyone's talking about.

It's all Perl with all the goodness and badness both that come from that, but works well. Supports multiple types of databases (MySQL, Postgres, Oracle), etc.

Good system for handling all tickets via e-mail. The wiki is a bit disjointed but has lots of info on integration with authentication systems (LDAP), and/or other setups that people have done. Initial installation and setup can be time-consuming, but once it's set up, it's stable and works.


Reply to: