[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?

• http://bitbucket.org/wez/mtrack/wiki/Home is where the project resides, in a Mercurial repository; you are welcome to clone it and work with it.

How is mtrack licensed?

• Modified BSD

What are some of the key features in mtrack?

• Trac style wiki syntax (all of its core syntax is supported)
• Subversion and Mercurial repository integration (API extensible to other VCS)
• Email notifications batch related information together to reduce the amount of mail you need to read; if you make 5 changes relating to a ticket in a 5 minute period you get one email with all 5 changes in it, instead of 1 per change.  Code changes that reference a ticket generate a single email with the ticket changes and the diff, not a separate email for each.
• Issue tracking with configurable components, priorities, severities, milestones.
• Define "projects" and associate components and paths within repositories with them to control who gets notified of changes.
• Flot based graphing of Scrum burn-down based on time estimates and recorded effort
• Wiki edits have in-built conflict resolution and the Issue tracker tries hard to behave reasonably in the case where multiple people are working on the same item.
• Uses the Gravatar service to add some personality throughout the application.
• Includes an importer to migrate your Trac project(s) into mtrack.
• Has a plugin/hook API to support both core and external enhancements.
• Uses the Zend Framework Lucene implementation for full-text search capabilities. 

Why didn't you use <Name of Framework>?

• Frameworks can increase development overhead and I wanted to get this done.  Also, if I had used a framework, I would have to defend my choice against the others ;-). I am not morally opposed to contributions that adopt a framework, but would want to carefully assess the impact on longer term maintenance before doing so.

How do I install mtrack?

• Installation Docs

How can I contribute to mtrack?

• By trying it out; I'm looking forward to hearing suggestions, comments and bug reports.  Please file them in the issue tracker: http://bitbucket.org/wez/mtrack/issues/?status=new&status=open and keep in mind that you may not get a response until the following weekend (or even longer!) due to my busy schedule
• By fixing bugs; if you've found and resolved an issue and want to pass a patch back to me you can do so either by attaching the patch or details on how to get at the patch to the issue tracker.  I recommend doing this by keeping your own fork on bitbucket as it makes it much more convenient for both of us.
• By building out and sharing new features; I'm very open to adding new features.  My preference is to enable those by making the core modular enough that new features don't have to be part of the main mtrack code to be used by it.  This will keep the the core light and make it easier to share modules.
• By fleshing out docs.  I'm the first to admit that mtrack could do with more documentation.
• Join in the discussion in the mtrack mailing list or in the #mtrack IRC channel on freenode.

You started this article claiming that all other issue trackers suck, but I think mtrack needs improvement

• I'm sure it does; it is still early days and I welcome your feedback (see above!)