Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Open-source trouble ticket systems



I've just setup Mantis and as a light weight bug tracking system, it's 
quite good. (Well, I've only used it for 1/2 a day or so, configuring 
it.) It has a nice feature to setup custom fields which makes it 
configurable enough to tailor to my clients needs. So far so good with 
this one...

Cheers. Steve.

www.mantisbt.org


Tom Metro wrote:
> John Abreau wrote:
>> I really like Request Tracker; I've been using it since 2000, and I've
>> been very satisfied with it.
>
> I've been using RT heavily for only a couple of years, and having used
> BugZilla for many years, I found RT lacking in several areas.
>
> I think RT excels as a general purpose ticketing system, particularly if
> you want strong email integration. But when it comes to specifically
> tracking software development, I find that RT is perhaps a generation
> behind the curve.
>
> For example, RT lacks a bunch of fields that are commonly found in
> software bug reports. They can be added, but its up to you to do that.
> The workflow process (the stages a ticket goes through) it provides is
> less ideal for software development (but again, can somewhat be
> customized). And then there are a bunch of little annoyances for
> software projects, such as the way it collapses white space in postings,
> thus trashing formatted code fragments. Also, unlike BugZilla, it
> doesn't automatically hyperlink references to other tickets (bugs).
>
> Despite this, I wouldn't necessarily jump to BugZilla for my next
> project. After years of using these systems it has become apparent 
> that what you really want in a ticketing system is a combination of 
> project management features (as it's common these days to track all 
> development tasks, not just bugs, using tickets), document management 
> features (wiki area for the bug description or specification), 
> discussion (per-ticket and project wide), notifications (both email 
> and RSS), and version control integration.
>
> Trac (http://trac.edgewall.org/) has been mentioned numerous times on 
> this list. On paper it seems to come close to meeting the above 
> requirements, but I've only had superficial exposure to it so far.
>
>
> Bill Horne wrote:
>> If I read the page correctly, RT won't run under Windows...
>
> Given that it is written in Perl, I'd be surprised if it couldn't. It 
> may need some additional software added to the machine, like a mail 
> transport. I'm sure the link someone posted has more details.
>
>
>> ...I'd like to know which open-source ticketing systems have been
>> deployed the longest and which ones have the largest user base...
>
> Both RT and BugZilla are among the oldest open source issue tracking 
> programs available. They probably both date back to the late 90's if 
> not earlier.
>
> Given that RT is more general purpose, I'd guess it might have wider 
> adoption among corporations, and perhaps a higher number of 
> installations, but I'd bet there are more people with BugZilla logins, 
> given its frequent use on popular open source projects.
>
>
>> Off the top of my head, in addition to the usual
>> who/what/when/why/where I'd like to have:
>>
>> * Quoted resolution date/time
>> * Expected resolution date/time
>
> What's the difference between these? The developer's opinion vs. the 
> project manager's opinion?
>
>
>> * Duration since start of incident
>>  * Hours
>>  * Business Hours
>
> One of the annoyances with RT is that times are tracked in minutes. 
> Not hours and minutes - just minutes. This gets even more annoying if 
> you're working on a scale of days.
>
> Neither RT or Bugzilla have a running clock since the incident was 
> reported, that I'm aware of (certainly not taking into account 
> business hours), but they both track the date the incident was 
> reported, and I think both will show the number of days old an 
> incident is in some reports.
>
> Both tools are fairly weak on some of these project management features.
>
>
>> * Duration since last callback
>> * Historical info for customer
>>   * Number of incidents
>>  * Average time tickets were open
>>  * Average Technician/Engineer time per incident
>>  * Average cost to repair
>>  * Duration since last incident
>
> I'm not aware of either tool providing canned reports for any of these 
> metrics, though some can be easily obtained by running queries through 
> the standard query UI. Others would require writing some custom code.
>
>
>> Of course, I'd like management screens:
>>
>> * Number of tickets open
>> * Highest duration
>> * Average duration past 24/48/settable (rolling)
>> * Tickets over n hours
>> * Tickets for top 5/50/settable customers
>
> While number of tickets open is easily obtained, as is tickets per 
> developer, project, component, etc. I think you'll find the others are 
> less easy to extract from BugZilla and RT. Both tools seem to focus 
> more on usability from the perspective of the individual developer, 
> and have less to offer for the project manager looking to gather 
> aggregate statistics.
>
>  -Tom
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org