MFCF's RT — Alternatives and Improvements

0. Introduction

0.1 Outline

0.2 Request

   From Fri Dec  1 05:50:48 2006
   From: "Tom Serviss" <>
   To: "'Ray Butterworth'" <>
   Subject: RT survey project

   I would like for you to assess the RT system.  We would like to have a
   report which outlines the strengths, weaknesses and constraints posed
   by the current system.  We would also like a similar analysis of the
   newer version of the RT system used by IST.  Once these assessments are
   complete, we would like you to make a recommendation as to whether we
   should stay with the old system, move to an instance of the new system
   on the IST server, or look at developing our own system.

0.3 Survey

   From rbutterw Mon Dec  4 14:41:27 2006
   From: "Ray Butterworth" <>
   To: mfcf-staff
   Subject: RT Survey - please respond

   Please take a few minutes over the next week or two to respond
   to this.  I'd like to hear from everyone.

   I'll compile (and probably paraphrase) the results without
   attributing them to any individual.

   If you include personal comments that you don't want included in
   the survey (e.g. something specific enough that it identifies you),
   please mark them as such.

   We're doing a survey of our RT system, trying to find out
   what we as users consider good about it and what bad.
   We aren't necessarily going to replace it with something
   completely different, but there are newer versions of the
   software available and there is a lot of room for customization.

   So, we're asking you to mail your comments to me (rbutterworth)
   about (at least) these topics:
     - What features do you really like and wouldn't want to lose?
     - What features are missing that you'd like added?
     - What features and bugs do you dislike and would like corrected?
     - Anything about the way we do or don't use the RT system within MFCF?

   They could be about the database structure itself, the web-form
   interfaces, documentation, or any other aspect you want to discuss.

   I expect that the "like" list will be fairly small and similar
   for most of us, but if there are some obscure features that you
   rely upon and think that others might not even know about,
   be sure to mention them.  (If we do make significant changes
    as a result of this, we don't want people to suddenly discover
    useful features have become no longer available.)

   The "add" list can be whatever you want.  Some things will of
   course be effectively impossible to add, but it's surprising
   how many apparently complicated things can actually be simple
   to implement.

   As for the "don't like" list, we expect to see a lot of suggestions.
   They might be simple bug reports about things that don't work as
   advertised, complaints that things don't work as expected,
   suggestions for how things could work differently, or even
   suggestions for significant reorganization and design.

   For bugs, specific details would be nice to get, but for
   everything else even vague generalities are acceptable.

   And please keep in mind who is compiling the results, and so
   realize that no complaint or suggestion is too trivial to consider.


1. Features Of Our Existing RT System

Our current request tracking system was adapted by MFCF from one of the earliest RT releases and highly modified for our own purposes (mostly by Fraser Gunn and Bill Ince, and later by Isaac Morland, all now with CSCF).

It is heavily used by all staff within both groups, and has become an essential tool in our daily routine, providing a current and historical record of:

Most of the following comments result from a survey of MFCF staff. They are not comprehensive, but do illustrate the kind of things that people care enough about that they have taken the time to report them. I've tried not to imply any relative merit among the many suggestions listed in this report. It is worth noting though that almost none of the suggestions received contradicted or conflicted with each other, and that except for a few minor points, I would agree with them all.

The features of our current request tracking system are divided into four categories:

1.1 Missing

Our current system has some obvious deficiencies and could benefit from some useful additions. Many of these are already handled by, or could easily be added to, a newer version of RT.

1.2 Good

It also has some locally added features that, as far as we know, are not provided by stock software:

1.3 Bad

Bugs in our current RT system are too numerous to list, but here are some that people find most annoying:

1.4 Ugly

Even when our system does work as intended, certain aspects of its fundamental design make it inconsistent and awkward to use and understand:

2. Possible Directions

Each of several solutions to our problem has obvious advantages over the others, but none of them are strong enough to be the obvious right choice.

Each of these solutions also has obvious disadvantages. In general these disadvantages can be seen in terms of the amount of human work they will require.

2.1 Design our own request tracking system from scratch.


The most ambitious option would be to replace the RT system with a completely new in-house design. This would enable us to:

  • implement it in a language that will run far more efficiently than the Perl interpreter and be easier to understand and maintain.
  • eliminate every annoying feature of the existing system.
  • add every missing feature.
  • have full control over every aspect of the software.


This would be, by far, the largest project, requiring a significant amount of dedicated labour, not only for the initial design and implementation, but also for ongoing maintenance and updating.

And for those that consider past investments as a useful factor when making decisions, it would make it virtually impossible for us ever to switch to the real RT system, regardless of how bad our own system turns out.

2.2 Upgrade our existing RT system to version 3


Version 3 provides many advantages over the ancient version of RT that we are running now. Our base version was picked up so long ago that I haven't been able to find anything listing all the features that the vendor has added since then. But some obvious enhancements include:

  • attachments
  • enforced dependencies
  • enforced policies
  • custom fields
  • better documentation
  • better defined API
  • ability to override default functionality
  • a command-line interface
  • full i18n support
  • mason-perl preprocessing of web pages
  • significantly improved source code
  • easier addition of local modifications
  • easier preservation of local modifications across version upgrades
  • Use of Mediawiki to manage content.


This would require extensive work to incorporate the local modifications that we consider worth keeping. In particular, we have created many customized web-forms and extra tables, and the software has access to other databases (e.g. inventory, uwdir).

Fraser Gunn, of CSCF, has now created an item to determine what features we added to the original version: RT#56353 - RT - document the changes we made and our design decisions.

Just as some people use the pretentious British style of spelling words with an -ise ending, rather than the correct everywhere -ize, RT's writers use the American alternate (like lite) spelling requestor, rather than the requester spelling that is correct everywhere.

2.3 Transfer our data to IST's RT system


Using IST's existing system (version 3) would provide all the advantages of upgrading our own system, without having to provide or maintain any hardware. It would also mean that MFCF wouldn't incur the overhead of managing the RT system or the machine(s) on which it runs, nor of installing vendor updates or backing up the data.

We would also have a choice of:

  • Sharing IST's configuration and database, which would provide full support from IST.
  • Having IST support a separate instance for us, which would allow us to make modifications and additions that IST might not otherwise allow.


In addition to the problems mentioned above, this would require a little extra work to incorporate the local modifications that we consider worth keeping. And if we went with the shared-data option, we would have to renumber all of our RT items and might even not be allowed to implement some modifications.

2.4 Go with an existing non-RT system


No obvious advantage.


RT's web site says: Every ticketing system sucks. Here at Best Practical we're really proud of the fact that RT sucks less than everything else out there ... ..
I've not seen anything that contradicts this fact.

2.5 Stay with our current software


Staying with our current software offers two very significant advantages over switching to a new version:

  • It's free.
  • It's already done.

And staying our course would not preclude making changes to eliminate many of the existing annoyances.


While we can change some of the features that we don't like, and add new ones that we would like, it's unlikely that we'd ever bother to modify the underlying code that does all the work, which presumably the vendor has improved somewhat during the previous ten years. We'd also miss out on features that might be too difficult to retrofit into the old code. And we'd have to track new features and improvements that the vendor adds and reimplement them ourselves (given our track record with the existing package, that isn't likely to happen).

The other choices would almost force us to perform a massive cleanup of the existing data. If we stay with the current software, experience shows that we're unlikely to spend the time on this desirable side-effect.

3. Recommendations

It's clear from the responses that changes need to be made to our current request tracking system, and given the lack of conflict between the suggestions, it's fairly clear what they need to be:

If MFCF were still in its golden age, I'd have no trouble recommending that we design our own system from scratch, market it worldwide, and become rich and famous. Unfortunately that isn't the case, and such a choice would require a large commitment of human time, a resource that, as far as I know, we can't really afford now. And even if we could afford it, perhaps there are other projects on which that time could be better spent.

If we are truly lacking in resources, staying with our current system seems like the only choice, though we could spend some time, in cooperation with CSCF, to clean up some of its more annoying features.

Otherwise, if MFCF is willing to commit the necessary resources, the best direction to take seems to be with asking IST to host our own RT instance. This would give us more freedom than sharing their system, while eliminating much of the ongoing responsibility of maintaining the hardware, data backups, and vendor updates.

4. Unanswered Questions

Even after we have made a firm decision about which direction to proceed, there will still be a number of issues to resolve: