rt/docs/design_docs/basic-definitions.txt

   1 (todo ... basically, those are untouched from 1.0)
   2 Ticket
   3 Queue
   4 (...more?)
   5
   6 Requestor
   7
   8   (...definition of a requestor .. blahblah)
   9
  10   I'm often doing a distinction between "Internal Requestors" and "External
  11   Requestors" (see below).  The system doesn't make any difference between
  12   requestors, but the distinction might be useful to discuss usage patterns,
  13   templates and configurations.
  14
  15
  16 External Requestor
  17
  18   Might be a customer or a potential customer.  The External Requestor
  19   should be treated as a VIP.  (S)he shouldn't need to see too much of RT.
  20   The support (s)he gets should be as personal as possible.  The external
  21   requestor might eventually get access to the Web UI, but only to track
  22   her/his own requests.  If you're not planning to use RT for handling
  23   external customers, all your requestors are probably "Internal
  24   Requestors".
  25
  26
  27 Watcher
  28
  29   Somebody that are "subscribing" to a queue or a ticket (or something
  30   differently).  Basicly, somebody watching a queue or a ticket should get
  31   all updates by email.  A requestor is a (special) watcher.
  32
  33
  34 Regular Watcher
  35
  36   People within the same organization, people that have read access to whole
  37   queues.
  38
  39   I consider "Regular Watchers" as well as "Internal Requestors" as more
  40   robust and capable human beeings than the fragile customers.  We don't
  41   mind letting them get entagled with RT, and we let them access the Web UI.
  42   They can live with beeing just the Cc or Bcc at an email.
  43
  44
  45 Internal Requestor
  46
  47   An Internal Requestor is usually internal to the company.  He might be 1st
  48   line support sending matters to tech support or similar. Might be an
  49   internal employee sending matters to tech support (or even 1st line
  50   support if he's not sure where to send matters).  It might also be that
  51   "ordinary" requestors actually might be treated as intelligent human
  52   beeings rather than VIPs, i.e. in open source projects ... we'll still
  53   call them "Internal Requestors" as they don't need the special VIP
  54   treatment.