ST To RT Investigation meeting - 2016-06-06

10am-11am. Hosted by Lisa; attended by Daniel, Lawrence, Fraser, Jim, Robyn.

Lisa's vision of the overall process:

• After this meeting, we then start poking at the existing RT queues; they will happily add new fields to the prod instance for us; we can get dev RT queues to test out existing (or possibly custom) module add-ons.
• Limitations include: there are behaviours that cannot be changed for us without changing for everyone; they don't want to go that route. (such as: behaviour of Admin CC always receives email for items they are on.)
  • however, there are lots of behaviours that are specific to a queue; we can get the list from the dev instance she will set up for us.
• She is motivated to help us get to "yes".

Lawrence:

• Timing: Is finishing implementation by next May acceptable to MFCF? Yes.
• Training: Lisa does training on a "when needed" basis; Jennifer is going to start doing training (as well as adding new queues). Lisa does forms-adding.
• Can we get access to create new fields?
  • Lisa and Jennifer can: create extra custom fields; queue owners can: make canned/custom replies to clients (messages when resolved tweaked); run scripts ...
    • permission to create custom fields requires permission to create everywhere... but they can grant permission to edit fields in your own queue.
  • Rather than using the dev instance for that- LIsa suggests putting this sort of testing into live (where Lisa is adding new fields, and we edit). Use the dev instance to test installing new modules.

Lisa:

• gave us a quick demo of adding fields
• Do they do field validations? Not really, however, they do userid canonicalization for auto-fill field via: weekly or semi-weekly, pull primary email addresses from LDAP.
• scrips (note missing 't') : run after each individual change to a ticket (eg., on correspond notify requestors and CCs)
  • when we get dev, can review all of them
• a project to improve incidence management is ongoing in IST
  • Daniel: how do you do change management? Lisa says it's fuzzy right now; she would be in favour of a "RT Group" for advance notification/input in advance; they won't make big changes without checking with us.
    • eg., Admin CC field currently not used; but will soon change to auto-email them on updates; they will handle change management by sending a short email to say it's being used and for what purpose.
    • Admin CC of queue can be set for the entire queue, which might match Omar's group's preferences.
    • we can add an "Owner" field as well, with multiple people listed (and set scrips to act on it)
• queues are a big area of change; do we only want a CSCF/MFCF split; or broken down by research area; or for "special projects" or...
• CC doesn't get all contents; but admin CC does
• how do we replicate "Owner" as we have it? Lisa sees three options:
  • admin CC can include everyone who was on our owner field.
  • discussion of breaking up items by Responsible/Owner to put owners in separate field.
  • specific queues, eg: queue for mfcf security; Robyn is admin CC for the queue; he sees all incoming work; Robyn assigns items to worker(s) and monitors for completion.

Lawrence:

• can people see each others' items in queues? yes, easily; we just tell Lisa the names of users and they will add them to the queue.
• can external apps get access to data?
  • Lisa demoed "Subscription" - ability to make custom queries which can be emailed daily/weekly
  • we could make a bot to hit the website and pull data we need.
  • [likely better: command-line access]

Next steps:

• Lisa will add dev queues and schedule training for this group - with Jeff sitting in to answer questions
• see https://uwaterloo.ca/rt for docs.

Post-meeting discussion:

• We're not convinced about the different usages of Admin CC vs owner. However we'll definitely discuss further. (Noting again: they are just putting Admin CC into practice for the first time, now).
• We want to drive from a "principle of least surprise" - eg, making the least changes to make it useful for us, without negatively affecting how useful our interface would be for non-*CF users, such as a co-op from IST working for us.
  • Notwithstanding, if there are changes that would benefit the rest of campus, we will have that conversation with Lisa etc.
• Overview of upcoming process: 1) they give our team privs and training in the prod environment; 2) we investigate and test implement custom fields with Lisa's help; 3) we identify things we know aren't there; 4) we expand testing to others in *CF with caveats about the things we know aren't there; 5) we gather lots more feedback and start planning for fixes or workarounds for missing features in order of criticality; 6) by the end of this term, we have enough information to recommend a go/no-go.
• It's a good sign that they expect to give us command-line access, which may allow sufficient querying to make our subscriptions db feasible. (vs. Lisa's suggestion of a daily email, and/or building a web bot).
• ST Priorities: are not going to be part of RT. However, it's not clear that we need them to be there. None of the managers rigorously use "Current" the same way Bill did, with good cause; our implementation team can come up with a good approach for CSCF and/or MFCF.
  • Due Dates: part of this puzzle. We have potential for much more effective use of Due Dates in RT; eg., daily report of upcoming due-dates. There is the ability to export-to-ical - which means we could subscribe to our own due-dates, showing up in the calendar program we already use.

-- DanielAllen - 2016-06-06

• RTmeetingsCSCFMFCF.docx: Lisa Tomalty notes from 2016-06-06 meeting