Technical Meeting

Daniel, Fraser, Robyn met (Lawrence was double-booked).

Agenda:

• reviewing relevant notes from last week's training
• consider decisions we need to make, e.g., changing process versus changing tools to work with our process.
• Any show-stoppers?

Discussed last week in training

Roles

• • RT suggests particular styles of work. One owner. Is our culture compatible with RT's changes from ST? We could consider how our roles match...
    • ITIL RACI: Responsible, Accountable, Consulted, Informed. - Responsible does the work. Accountable is only one person. Consulted is asked for input, and their input can be overridden. Informed does not have input component.
    • RASI: S = Supporting. This might be more like what we do.
  • Our owner list = Responsible + Supporting.
  • Our Responsible = RACI Accountable.
  • Our admin CC = RACI Informed.
  • It's clear that RT (elsewhere on campus and the outside world) uses Admin CC differently, a mishmash. RT allows setting permissions differently.
    • We don't want to get sucked into the swamp of confusion.
    • Perhaps we can propose role improvements to RT for IST's benefit.
      • Our "Responsible" is somewhat ambiguous.
        • Can include: Manager; POC in CSCF; or product owner. And MFCF doesn't pay much attention to Responsible.
      • But "Admin CC" in RT is really ambiguous, and confusing.
      • Possible fix: add role for "Supporting". (Discussed additional issues and suggestions...)
  • Custom roles are 4.4, which IST isn't planning to deploy before May 1. [ edit 27 Jan to add: TBD by Jeff and Lisa; hopefully done in early April ]

Some other topics discussed last week that have bearing on our work:

Time-tracking

• Lawrence's need for subscription and time-tracking to work completely; May 1 date seems critical for time-tracking and budget.
• Options are: 1) our lookup tools can see both ST and RT; or 2) no time-tracking / updates in ST after May 1.

Bulk ticket creation

• See below. not critical.

Data validation on input - e.g., userid, hostname

• training had approaches described; we can do these.

Summary text field bigger

• easy, via CSS
• Also, summary can be moved to another section of the interface such as Basics.

Look items up from other data sources e.g., inventory

• populating fields - training had approaches described. We can do these.
• topic for later: if IST migrates to using RT's asset management, are there risks to us running our own inventory system?

SLAs as possible expansion of process - potentially useful.

Articles as possible expansion of process - potentially useful.

A number of external modules were described - potentially useful.

• RT::Extension::AdminConditionsAndActions (will become core- web UI for managing RT conditions and actions).
• RT::Extension::TimeTracking
  • weekly view includes time spent on each item.
  • Add to time worked: date (to log time for yesterday)
  • "Users:" see total time worked per person
  • RT::Extension::TimeTracking::Automatic - add n minutes for basic overhead

Scrips can automate just about anything RT does - potentially useful.

• automate fixing data upon submit? To be determined.
• can run sub-processes via shell
• automatically create sub-items based on criteria of parent-item ( https://docs.bestpractical.com/rt/4.4.1/RT/Action/CreateTickets.html )

Discussion of potential showstoppers

2) ticket "locking"

• ST prevents updates from stepping on each other by detecting and merging. Probably not critical.
• RT has "all or nothing" model - which partly relates to "single owner of an item" philosophy; also users usually operate in more selective modes not "Jumbo" which corresponds to our interface.
  • we might have higher quality metadata if everything is in your face on the edit page. Would we want to modify default view to show all data by default?

3) Roles: do we need 4.4 to do roles the way we expect?

• alternatives: 1) pass ticket to new owner- preventing parallel work on that ticket; 2) proliferate sub-tickets, which is IST's recommendation; 3) overload adminCC- which is IST's other current practice; and is ambiguous.
• Discussed roles in a RACI context.
• Omar and Lawrence are inclined to make do with using IST's 4.2, and perhaps considering custom roles with IST later (though we are keen to keep things simple; and generally use the same options as IST so we don't have confusion about "if I'm in this queue, I work this way, versus in that queue").
  • Counterpoint: IST doesn't have a current set practice with adminCC; a much cleaner solution is to propose a "Supporting" role, which could be adopted anywhere/everywhere on campus.

-- DanielAllen - 2017-01-23