ManualIntroduction

Up: UserManual --- Next: ManualRequirements

Welcome to Request Tracker(RT), your new favorite ticketing system. This introductory chapter will explain what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead to another chapter.

About Ticketing

When people say "ticketing," they're talking about buying a stub of paper that gets them into an event. Our type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. The current common phrase seems to be "issue tracking".

Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs and answering customer service requests.

Since tickets are detailed records, you might not want to bother using it for one-off events ("Buy Bob in HR a going-away present.") You also shouldn't use it for tasks that are too broad ("Save world") or too granular ("Go to phone." "Pick up phone" "Lift finger." "Dial '9.'")

About RT

RT is a ticketing system for small- to medium-sized organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:

• Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com
• RT records the new issue in its database and sends Billy an electronic "ticket stub" containing the new ticket's ID number and, ideally, some helpful information. He can refer to the ticket stub if he needs to send another email later.
• RT forwards Billy's email to a set of staff members.
• One of the staff members, Jane, is the company's Bananamaster expert. So Jane takes over Billy's issue and drafts a reply to Billy, which RT automatically records and forwards to him.
• Billy is a happy customer; Jane resolves the issue and heads down to the pub for a pint.

This workflow is flexible, can be customized for your organization, and need not involve bananas.

RT concepts

There are some words and phrases you should understand in the context of RT before you begin. See RTGlossary for more definitions.

A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."

Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20. 50, and 75 may vary from organization to organization, but there should be an organizational policy or every ticket will get rated 99 by anxious users. ManualAdministration contains a useful model for setting organizational policy for priority.

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

• NEW: the ticket has just been created and hasn't been touched yet.
• OPEN: the ticket is getting worked on
• STALLED: due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
• RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
• REJECTED: the ticket is not the staff's problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
• DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

• OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.
• REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
• CC: someone (or someones) who should get copies of any replies that go to the requestor. This might be the requestor's boss, sales rep, etc. This person will see the emails but doesn't necessarily have the right to work on the ticket.
• ADMINCC: a Cc or Ccs that also gets copies of comments and generally are allowed to work on the ticket.

We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.

You can also, as you work on a ticket, define its relationship to something. Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

• DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
• REFERS TO: the ticket doesn't need the other ticket, but it would sure be useful for you to look at it. The converse is referred to by.
• PARENT: a big, general ticket ("Move house.")
• CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

CustomFields are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in ManualAdministration. An example custom field might be Resolution: FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... (If you think that example was stolen from Bugzilla, you have much to go on :-)

Scrips are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in ManualAdministration. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.

Now that you are (we hope) clear on the concepts, you're ready to start using RT.

Up: UserManual --- Next: ManualRequirements