MantisBT vs. RT3

I’ve been praising Best Pratical’s RT3 (aka Request Tracker) for a long time.  So at my new job, given a new start, I thought that I maybe need to explore other options and widen my horizons.  After all, the needs were much less and much simpler.  We just needed a bug tracking application for three people or so and for a single project.  There was a possibility of more people joining the team later and more projects starting up, so I didn’t want to limit ourselves too much.  But immediate needs were quite simple.

After a good look around, I decided to give Mantis Bug Tracker another try.  I remember using it for a bit back when the project just started.  I even remember patching it to fit my needs back then.

During those few years that I haven’t looked at MantisBT it grew and developed quite a bit.  It is a stable, feature-rich, yet simple to manage application.  We’ve used it for the whole two month before our needs changed again and we started looking back at RT3.  Never-the-less I am glad we used it and got experience with another tool.  I got a few ideas out of it, which I will be implementing in our new RT3 installation.  Below are the few things that I loved and hated about the MantisBT.  Maybe you’ll find them useful.

The good:

• Easy installation, configuration, and management.  MantisBT is a PHP application and we all know how to handle those by now.  Drop it in the folder, create database, edit the config file a bit and you are done.  Use and enjoy.  MantisBT also provides web pages for administrator user to handle most of the day-to-day tasks.
• Changelog and Roadmap.  I think these two things are the best part of MantisBT.  These two screens provide one click access to tasks grouped by the release version.  Changelog shows all tickets fixed in each version of the project and roadmap shows all tickets that need to be fixed for each version of the project.  A quick look at changelog and your boss or sales team know how to excite the customers.  A quick look at roadmap and your development team knows exactly what to work on now.  Brilliant!
• Ticket categories.  This is trivial to do in RT3 with a custom field, but it was still nice to have out of the box.  You can define categories for your bugs, such as User Interface, Performance, Security, etc.  Having category as a required field, provides you with some nice overview statistics, where you can see what sort of issues you are getting the most or spend most time on, etc.
• Wiki integration.  While we haven’t heavily utilized this feature, it still was helpful on a few occasions.  You can integrate MantisBT with DokuWiki and have separate pages for each ticket.  This is useful when you need to have sections of third-party documentation handy or several design templates that were discussed but not chosen, etc.

The bad:

• Email integration.  I was rather surprised as to how weak the email integration in MantisBT is.  While it does send out notifications on ticket updates alright, you need to install plugin and create a POP/IMAP mailbox to create tickets from emails.  And even when it works, it’s weird.  Like if you want to use it for automatic bug reports, for which you don’t want to send notifications out (it was a bot who created a bug report anyway).  I spent almost two days tweaking the setup and I got it sort of working, but it’s far from perfect.

The ugly:

• No way to merge tickets.  This functionality comes in RT3 out of the box and it is extremely useful in two particular scenarios: when you deal with users, who often send a bug report, forget to add something, and send in another ticket for missing stuff; and when you are dealing with automated bug reports, where you’d want to merge several occurrences of the same bug with slightly varying data into a single ticket.
• No easy way to extend the system.  I know, MantisBT being a PHP application you can always write additional modules and classes, and patch existing code.  But after the Scrip concept of RT3 it seems too much.  Automatically linking tickets to each other if there is a reference inside the ticket update (like “we’ve fixed this problem in ticket #123”), automatically resolving certain tickets after a certain period of time, and so on and so forth – for all of that you’ll need to be writing code in MantisBT outside of the administration.

The above only covers the major things that I came across.  There were plenty of small things that I liked and disliked, but I won’t bother you with the unimportant.  As I said, I am glad I tried the system and I was pretty satisfied with it for the needs we had.  Now things are different and we need a different solution.  And I know that RT3 fits the bill.