Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Request Tracker / Request Tracker 4.0 / Terminology

Terminology

A definition list of terminology used by Request Tracker
  • Ticket - A central place to store information about a single, specific issue or task.  Each ticket has a number as an identifier (e.g., ticket 105), and all information related to the ticket, regardless of the contributor, is displayed chronologically in a single web page in RT.  This threaded approach to storing related information offers a significant improvement over the user of e-mail.

  • Queue - A queue is a high level grouping for tickets.  Each ticket resides in a single queue, and if necessary, a ticket can be moved from one queue to another.  Often queues are created based on who will be managing the queue, that is, what group of people will be responsible for resolving the issues or performing the tasks in the queue.  For example, in Pathology Data Systems (PDS), the people who maintain control files are usually separate from those who maintain the code base.  Within the group of people who maintain the code base, PDS has three primary divisions:  CP, TM, and AP.  So one reasonable set of four queues for PDS might be Control Files, CP, TM, and AP.  By separating tickets into these hypothetical queues, the people who maintain control files can see control file related tickets without needing to sift through programming related tickets.  Similarly, the people who maintain the CP code base will not need to sift through a list of TM issues, etc.

    Another reason for storing tickets in different queues is that it is possible for the RT administrator to define custom fields for a ticket based on the queue the ticket is in.  For example, one type of ticket (e.g., tickets for requests to gather patient information) may require a field that allows you to specify whether or not PHI is involved in the request, and another type of ticket (e.g., tickets for requests to make changes to software) may require a field that allows you to specify the names of the programs that need to be changed.  If both of these types of tickets were placed into the same queue, then both types would need a "PHI Yes/No" custom field and a "Programs Modified" field, but it may not make sense to ask whether or not PHI is involved in a program change or which programs are involved when gathering patient information.  By creating two queues, the tickets placed into one queue can have the "PHI Yes/No" field, and tickets placed into the other can have the "Programs Modified" field.

  • Requestor - The person who is making the request, which may or may not always the person entering the ticket into RT.  By default, RT assumes that you are the one making the request, but if you are entering a request on behalf of someone else, you should change the value in the requestor field from you to the actual person making the request.

  • Status - The status of the ticket determines how much, if any, progress has been made in terms of resolving the issue or performing the task.  RT has the following status options available.
    • new - The ticket is brand new and no one is working on it yet.  This is the default status when you create a new ticket.

    • open - Someone is actively working on resolving the issue or performing the task outlined in the ticket.

    • stalled - Although some work has been done, the ticket needed to be put on the back burner, perhaps because of a need to address higher priority issues.

    • resolved - The issue in the ticket has been resolved.

    • rejected - Someone has determined that the ticket is not valid.  For example, someone reported a problem, but investigation reveals that the perceived bug is actually an intentional feature.

  • Owner - The person who is currently responsible for addressing the issue or performing the task in the ticket.  The owner can- and should be changed when the responsibility for working on the ticket changes.  For example, if a programmer has completed alpha testing and the update to the program is ready to be turned over for testing, the owner should be change to the person responsible for that testing.

  • Cc - A list of e-mail addresses where e-mail messages will be sent when someone replies to- or resolves a ticket.  E-mail is not sent to anyone on this list when a comment is added to the ticket.  The Cc list should contain the list of people who have an interest in the ticket but are not primary stake holders.

  • Admin Cc - A list of e-mail addresses where e-mail messages will be sent when someone replies to- or resolves a ticket.  E-mail is also sent to everyone on this list when a comment is added to the ticket.  This Admin Cc list should contain the list of people (other than the requestor) who are primary stake holders.

  • Subject - A description of the issue in the ticket.  The subject is a primary identifier of the issue in the ticket, allowing people to find what they are looking for quickly.  Therefore, it is important for the subject to be concise and unambiguous.

Document Actions