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 ]

ST RT RASI
Owner Owner Responsible
Other owners N/A Supporting
Responsible N/A Accountable
Admin CC Admin CC Informed
Requester Requester  
CC CC  

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.

Discussion of potential showstoppers

1) mass-creation of dependencies. However, we have the ability to customize RT code, pulling in ST code, to do this. Not critical.

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

Topic revision: r10 - 2017-02-21 - FraserGunn
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback