Issue-tracking software suggestions needed.

[reddragdiva]

At work, we use Remedy, and it's crap. We want something better.

We want to keep track of a combination of quick fixes needed, larger issues, short projects, long projects and open-ended projects. Bugzilla fits this perfectly — except the customers would like to be able to watch issues in progress. So we need something we can write the awful truth in without customers seeing anything unsuitable for their consumption. Ideally we'd like something that's as suitable as Bugzilla for us and will give a safely sanitised version accessible to the customer. (Possibly a forked version of Bugzilla.)

Suggestions from those who've used something suitable or almost-suitable are welcomed. Oh, and it has to be free, of course, because we spent our money on Remedy.

Comments

[ladykathryn.livejournal.com]

Technically speaking, RT (http://www.bestpractical.com/rt) is a help desk ticketing system, but I use it for issue tracking with my team as well. And it does have the "sanitized customer view | nasty backend commentary hiddden" feature, which I find to be extremely helpful.

[reddragdiva]

How's it cope with long projects and open-ended projects, particularly compared to Bugzilla? (e.g. any years-long feature request or really hard bug in Mozilla or other software projects.) I know vatine's work at an ISP uses or used Bugzilla, and that it was not quite ideal as a ticketing system. (I eagerly await him weighing in!)

[ladykathryn.livejournal.com]

I've never used Bugzilla, so I can't compare, but we have some fairly long-standing issues even among our usual work requests that seem OK.

[aca.livejournal.com]

We use RT here at MPC (http://www.moving-picture.com/).

The basic structure is similar to Bugzilla. You have queues, in these queues there are tickets, whereas with Bugzilla it's projects and issues/bugs? (I've not used Bugzilla in a while).

The biggest problem with RT is how configurable it is. You really need to know what exactly you want to do and spend time setting that up as RT in its default config is a little clunky to be customer facing.

Once set up I think it will serve you very well.

As far as long running problems go, you just keep the ticket open. You can even have dependencies, relationships between tickets, approvals processes, all built in, so you can easily break tasks down into bite sized chunks and track progress that way too.

Personally, I've been working with and admining an RT install for 3 years now and I'm not sick of it yet. Must be a good sign. :)

[weatherpixie.livejournal.com]

Dunno how it would work with your requirements, but we used a tweeked version of RT here, up until we replaced it with something we paid for, and now, all the worker bees would like RT back please. The shiny new product now has some cgi wrapper around it to make it more like the old RT based system...

[vatine]

We went from Bugzilla to RT. RT 0wnz Bugzilla's socks.

[vatine]

Of course, RT really could use a bit of sane workflow grafted onto its back-end. Proper workflow makes usable issue-tracking systems go from "usable" to "pretty decent, really". 'Tis a bit of a shame that none of the dedicated bug-trackers actually manage to beat a decent DMS from a usability POV. :(

[reddragdiva]

DMS?

[vatine]

"Document management server". Think "version control" and "workflow handling" for, well, documents. Also decouple "document" from "file" (a "document" is one or more data blobs that something, somewhere can handle in a sensible fashion, the 'Project Unnamed' document consists of about 15 source files).

[sbp.livejournal.com]

Have also been using RT for almost 2 years for day-to-day requests, support, customer orders, and planning stuff. It's pretty customisable too. But again I've not used Bugzilla.

[dennyd.livejournal.com]

Patch bugzilla?

*runs*

[reddragdiva]

Don't run yet - I'm hoping someone will point me to a project that's done just that ;-)

[utile-et-dulce.livejournal.com]

no I'd suggest that you do run rather than do that.
The maintenance of a patched bugzilla could become an expensive issue.

[reddragdiva]

Well, yes, there is that ...

[damned-colonial.livejournal.com]

Bugzilla is written in very very bad Perl. Patching it is nightmarish.

RT has a plugin/template sort of system that allows for a certain amount of customisation while still being upgradeable. That's one of the things I like about it.

Its email integration also seems better, but I hear that Bugzilla's has improved since the one I was familiar with.

[utile-et-dulce.livejournal.com]

eventum
http://dev.mysql.com/downloads/other/eventum/
http://dev.mysql.com/downloads/other/eventum/features.html

should fit the bill
is trivial to install and is free :)

[kineticfactory.livejournal.com]

I've found Trac (http://trac.edgewall.org/) to be pretty good. It has issue tracking and (fairly decent) built-in wiki functionality and integrates with Subversion.

[wechsler.livejournal.com]

Trac's fine for what it does, but it doesn't handle ticket relationships or customer-friendly views.

We use it constantly for project management, but it's not likely to fit Diva's needs.

[ashbet]

Looks like we're not the first to suggest it, but signalii (Kyle) also recommends Trac. He says that the built-in wiki is very handy :>

-- Andi <3<3

[aidan-skinner.livejournal.com]

I'm pretty sure mainstream modern bugzillae can do what you want. bugzilla.novell.com and bugzilla.ximian.com certainly both have employee-only options, probably done with groups (http://www.bugzilla.org/docs/2.20/html/groups.html).

[reddragdiva]

Unless I'm misreading, 'groups' appears to be marking given bugs as entirely employee-only, rather than having some form of public and less-public comments on an individual bug.

[aidan-skinner.livejournal.com]

Oh, sorry, misread what you were asking. Bugzilla also supports private comments, which is definately what you want.

[incy.livejournal.com]

At my ex-place we used Raional Clearcase and Clearquest:
http://www-306.ibm.com/software/rational/

[reddragdiva]

Yes, because you worked in the financial sector and they have the money to pay Rational's ridiculous prices!

[mr-tom.livejournal.com]

Trac and Jira are the ticket-trackers of choice round here. Trac is nice.

[zenmonkeykstop.livejournal.com]

Funnily enough, we have Remedy, Bugzilla, *and* RT in use here. RT apparently has pretty much shaken out as the best for the admin side of things. Remedy's a pain in the hole and Buzilla is only really good for bug-tracking.

[aidan-skinner.livejournal.com]

The thing that got me about Remedy (we used to use it) was that the client made my eyes bleed.

It's hard to type when your keyboard is all slick and sticky at the same time.

[shamus9999.livejournal.com]

We use FrontRange's HEAT here. It's intended as an incident tracking system. They're currently trying to turn it into a root-cause trouble tracking system as well... which means that *I* have to try to make it jump through those hoops, since I'm the lead administrator of the system. At least they've given up on trying to use it for asset and project management. Now if I could just get the lusers to enter servers under the provided Equipment profile rather than the People profile.

One feature HEAT does offer is in its journal entries. Ther's an internal entry section that the techs see and an external entry section for the end-users. It should be relatively trivial to add a similar field to Bugzilla's database and modify the front end such that external users only see that field.

[chrysaphi.livejournal.com]

I'll throw in another vote for RT, having been paid to work on the software itself in the past. Its all-singing-all-dancing nature makes it complex and effort-intensive to set up, but it works quite well after you're past the setup phase. Also, the complexity of the setup pretty much makes you come to terms with what your workflow actually *is*, which is often a good exercise to go through.

There is a reasonably-sized support community as well, at wiki.bestpractical.com.

RT

[ewen]

I, too, highly recommend RT. I use it both for my own company and at a bunch of clients (many of whom I suggested it to).

RT is vastly nicer to use than Bugzilla IMHO, particularly since it's possible to mostly interact with a well setup RT via email (eg, reply to email notifications from RT and it'll go back into the ticket).

RT distinguishes between "comments" and "replies" (comments being internal stuff, and replies being customer-visible stuff). This distinction is certainly maintained through the email sent out, and I think (but have never needed to verify) that this also applies to what is visible in the web interface. (It's definitely got quite fine grained security over other things so I'd be very surprised if it didn't restrict customers from seeing internal comments -- of course one has to choose the right option when entering things one doesn't want customers to see!)

Setting up RT to be "just right" takes quite a bit of work (and thought about how to best utilise multiple queues, etc), but it's possible to be fairly productive out of the box.

I've never had any _really_ long term, heavily used, tickets in RT so I'm not sure how it copes with intensive long term use on a single ticket. (Most of my "development" tickets tend to be 3-6 months long, and only see 30-50 updates to the tickets; this is in part because I tend to split off parts of the job to other tickets and just make them dependencies of the larger task ticket.)

Ewen

Re: RT

[sbp.livejournal.com]

I'd be very surprised if it didn't restrict customers from seeing internal comments

It certainly does. We've lately gone live with a customer-facing interface to our RT system, as part of their general support site, and they can only see our official replies to the ticket, and their correspondence too. And they can only see tickets they requested, so they can't start querying the system for random tickets. Seems to work so far.

[heliumbreath.livejournal.com]

RT, man.

We used it for several years in an ISP environment and swore by it often, at it rarely. People were Upset when we got borged and had to migrate away from it.

By default, it wants an Apache instance and the rest of the machine to itself, FreeBSD or Linux are fine, but I got it working in a mortal-user account on a Solaris Zeus hosting server using FastCGI as a shim. I probably still have the scars, but I was proud of myself when that actually worked.

[xlerb.livejournal.com]

From what little I've seen of RT, it ought to be configurable into doing whatever you want. I got it to work using FastCGI and SQLite on NetBSD, sharing a host and an Apache 1.x instance with a bunch of other mostly-ignored random testing stuff, and don't recall it being more than usually painful; but that was a while ago.