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.
Nate
Reply to: