We’ve been using Trac on a project lately, and it’s a good example of an otherwise decent product being rendered almost completely useless by a simple problem. To be clear, we’re using Trac for defect/issue tracking, so if you aren’t using that part of it, this wouldn’t affect you. The rest of the system seems OK, though I’m not sure why integrating SVN commits into tickets requires some hack via Perl script (that won’t work for us). However, that’s just a lack of convenience, the real problem is the way it handles the chain of custody for tickets. Here is Trac’s state diagram for tickets:
I’ve worked with many different issue tracking systems, and if you have too, you’ve probably already noticed what’s missing. I call it the “full circle” concept for lack of a better term. The crux of the idea is that the person who opened the bug should be the only one to close it in most cases. Trac does not have this. The reporter can reopen the ticket, but a closed ticket basically falls off everyone’s radar, so no validation or verification would take place. Here is the state chart with the step I’m referring to:
Even on a small team, without this step we’re running into people with clogged-up queues because it’s pretty common for developers (ticket resolvers) to also create tickets from time to time and assign to another developer. We’ve take the safe route of reassigning to the reporter rather than closing, so things should be validated before closure, but this makes the ticket queues much larger and more difficult to manage, and sometimes tickets don’t get closed until after the fix has been published.