[Updated to add IRC and Google Groups links]
I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way. They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).
We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes. We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.
However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things. As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.
Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow. What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis. It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.
I chose to implement mtrack in PHP rather than continuing to extend Trac in python. My primary reason for this is that I've seen web apps written with Perl and Python, and while there are certainly guru developers out there that can build some awesome apps, those languages don't really lend themselves to web development and that limits the scope of potential contributors. While I can probably persuade some of my colleagues to code python web bits, I'll find it much easier to persuade more of them to code PHP web bits. I'm sure this property extends outside of our organization.
We've been running our engineering department on mtrack for a couple of weeks now (after a period of running it in parallel to Trac) with just under 20 or so people using it actively as part of their day-to-day activities, so I feel comfortable in making this blog post to solicit input from the broader community, both in terms of suggestions and bug reports as well as potential contributions.
While I am soliciting feedback, I'd like to emphasize that this is still relatively young and that there is no support and no warranty; if you are the cautious type, this is not the time to try mtrack.
And now for some Anticipated Questions to pre-empt FAQ:
Where can I get mtrack?
How is mtrack licensed?
What are some of the key features in mtrack?
Why didn't you use <Name of Framework>?
How do I install mtrack?
How can I contribute to mtrack?
You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement