We spent most of the meeting discussing IST process in RT (and how ours might differ).

RT Process / workflow in IST

• Process: generate RT items via 1) email; or 2) form (see https://rt.uwaterloo.ca/SelfService/Forms/index.html )
  • email rt-queuename@rt.uwaterloo.ca
  • RT Forms Tool to generate forms
• tickets assigned to queue and owner
  • can auto-assign ticket ownership
• solving problem, requestor notified, ticket updated and resolved (correspondence can have custom email content/footers, including "resolved" email feedback form.

• Process for requestors: login via https://rt.uwaterloo.ca/SelfService

• Who gets emails?
  • Requester: NOT comments; yes when correspondence/replies; submitted/resolved
  • Queue Admin CC's (different from CC'd on ticket) - when tickets are put into their queue.
    • would
  • owner / cc / admin CC: comments go to owner and cc-of-ticket
    • currently adminCC doesn't get email.

• Who sees what? ...
  • some custom fields not visible to requestor or CC-of-ticket

• mapping our roles / process
  • we use "owner 2+" role which doesn't map to CC, or adminCC as currently defined. - eg., needs to get all the email generated.
  • we use "responsible" for point-of-contact for a course or researcher... and get all email? which is different from IST's queue-owner.
    • can we set up different queues for each point-of-contact? no.
    • possibly add "responsible" field?
    • "approver" by queues? But that's for all entries in the queue, probably.
  • what actions need associated with these fields? (eg., emails sent?)

• statuses: new -> resolved (currently)
  • someone other than requestor touches it: new->open (within a month)
  • closure custom field - currently not effectively used.

What will we discuss with BP in January?

The remainder of the meeting was to discuss what topics we ask the BP consultants for Jan 18/19. Lisa wants to get them our set of topics ASAP (with recognition that it may be a rolling target; we might solve things before the meeting and come up with new items).

• batch creation
  • Robyn will write up current uses, and send to Lisa.
• custom branding? (Robyn to discuss with MFCF)
• Possibly roles discussion with BP? Only if extra time.
• given a machine name, look it up in our inventory system, return the associated location, and auto-fill the location field in RT
  • Jeff/Daniel will investigate as well, in advance.

"Nice to have"

• appearance/size of the custom "Summary" Field

Remarks

• We're wrapping up the term with some of our project goals completed, and others deferred. We are still able to say there aren't any strong "no-go" indicators; we plan to proceed in the Winter term with further development/implementation, leaving the possibility that we discover that some implementation features won't be there, leading to a final "go/no-go" decision before May.

Further discussion on Roles

• CSCF/MFCF will discuss whether we need something like "secondary owner" and/or "responsible"
  • IST will add one or both, if we ask for them; they will probably make the roles available to other groups if it makes sense
  • In general we'd like to work the same way as the other groups in RT, so we don't want to add roles unnecessarily. (But if a role is helpful across campus, that is a sensible addition).
• We spent a while today talking about "responsible." Fraser says: he uses Responsible to signal that he's the POC on a course, but others are doing the work. Robyn notes: MFCF doesn't tend to use it as rigourously as it seems CSCF does.
  • Conjecture: CSCF Managers may find their needs are met by searches (and/or batch automated reports) within ther queue. This will match items that would have them listed as responsible.
    • Counter-conjecture: do managers (and workers) want to look up "things Fraser is responsible for, but not owner on?" Fraser notes that his own use was trained by Bill, and he notes the occasional time Bill said, "You're not the owner, but you are responsible, and nothing has happened on this ticket for a long time."
    • Perhaps, early in the new year, we could discuss with other members of CSCF/MFCF, whether they rely on Responsible.

-- DanielAllen - 2016-12-13