Using an Issue Tracker (RT) for Production Line

I don’t think this is a radical idea, but @adr thought it was a cool idea and encouraged me to do a write up, so here it is.

Use Case

RT, much like other issues trackers, was created with IT support in mind. Although rather than IT development, it was meant for IT help desk situations.

In my situation, I oversee accessible format production of books. However, not everyone works in one office (or even one time zone for that matter), so we needed a way to keep track of which books were being worked on and by whom.

Why RT?

Simply because this is what we were already using. Interestingly, we used an existing queue, but honestly, I would suggest creating a new queue.

Creating a new queue is very simple for an administrator to do and allows for specific users to have permissions within the queue.

Work Flow

When new book requests come in, they automatically go to the correct queue based on the email address the request is sent to. (Users fill out a form, so they wouldn’t even think about this.)

Someone will do the usual things such as acknowledge the request and a few other things. I will look it over and assigned a priority and tag.

Based on the tag (which marks which are ready for production), a saved search and dashboard are created with the default sorted by priority order (highest to lowest) then date received (oldest to newest).

RT production

Any of the users that are involved can then take a ticket when they start working on it.

It’s also useful that whenever staff have issues, they can also make a comment about it in the ticket and the administrator will get a copy, and/or choose to cc other staff members.

The solutions to the problems can then become a knowledge base.

Recommend for Everyone

So far, RT has worked well for us. It helps everyone on the team keep organized, ask questions, and answer questions. RT is also easy to use so it required very little training and just a couple of simple tutorials are enough for new users and for existing users to refer to.

I would recommend for any organization to make use of issue trackers wherever appropriate regardless of whether they work remotely since it means being more transparent to more people and can help answer questions without having to ask someone (because what if they’re absent that day?), in addition to the other advantages I’ve mentioned already.

Take Away

While issue trackers are traditionally made and used for IT departments and projects, I think there are a lot of use cases for them.

If it fits your workflow, give it a try whether it be RT or another issue tracker.