Tues Nov 22 2016

Attendees: Jennifer, Lawrence, Daniel, Fraser, Jeff,Lisa, Jim, Lori.

Notes from Lisa.

Action items this meeting

• Lisa: ask consultants re: bulk dependent ticket creation
  1. Update: Lisa sent them an email Nov 22
• Jeff/Daniel explore how to pull time worked data from rt4.4
• Next meeting re: RT training ..explore roles
• MFCF/CSCF staff to explore critical features in existing RT 4.4 and send list of features they cannot do to jeff/lisa/Jennifer by December 7^th (a week before dec group meeting)

Action items last meeting

1. MFCF/CSCF staff:
   1. experiment with RT 4.4 and create a list of questions relating to critical factors and features to bring to Nov meeting
   2. Reach out to Lisa/Jeff if questions over next month
2. Lisa
   1. Done:Send this to the team
   2. Planning
      1. Done: IST project intake (done)
      2. Charter
      3. comm plan
      4. wbs
      5. roles and resp
      6. Other
   3. Done: Schedule a separate meeting to discuss IST/UW RT workflow and specs for new queues and what done when new queues/forms created

1. Review (see NOTES below):
   1. Critical features and nice to haves (see ‘Critical Factors and Features’ sent from MFCF/CSCF)
      1. i. - We'd like to add a summary field to the dev instance- ideally, appearing prominently, so we can tell at a glance what work is remaining on an item.
         1. -I have added a ‘Summary’ custom field to the MFCF-test queue on the dev instance (e.g. see: https://rt44-dev.uwaterloo.ca/Ticket/Display.html?id=525690 ). You will see it in the Custom Fields section and can add to it by clicking on Custom Fields and then entering text into the Summary field. (the size of the field can be increased by dragging the bottom right hand corner)
         2. ii. - How might batch-dependency creation work? can RT create dependencies via email? (I see in your latest notes you've mentioned "search then batch update" - maybe we will want to see that in operation). GOAL: not merely to record a collection of dependencies that already exist, but to automatically create a collection of dependencies.
            1. -batch-dependency seems to be possible (regarding doing this via email, see 2. Below). To do this in the UI: Create a Search and click ‘Add these terms and search’; it will then show you the search results; then you can click the ‘Bulk Update’ link at the top; in the Bulk update screen, you can scroll down to the ‘Edit Links’ section and fill in the dependencies as appropriate.
            2. Via email we can (exact details will need to be explored):

               our @REGULAR_ATTRIBUTES = qw(Queue Owner Subject Status Priority FinalPriority);
               our @TIME_ATTRIBUTES = qw(TimeWorked TimeLeft TimeEstimated);
               our @DATE_ATTRIBUTES = qw(Due Starts Started Resolved Told);
               our @LINK_ATTRIBUTES = qw(MemberOf Parents Members Children HasMember RefersTo ReferredToBy DependsOn DependedOnBy);
               our @WATCHER_ATTRIBUTES = qw(Requestor Cc AdminCc);
               

               1. For more details see https://github.com/bestpractical/rt-extension-commandbymail
         3. iii. - if we've started an item that is handed off to an IST queue, is our viewing access limited to those *CF people who are specifically listed as workers/CCd on the item?
            1. -regarding CSCF staff seeing tickets that are created by CS staff that are passed along to IST: For some IST-* queues we have opened up viewing of the tickets to other IT staff on campus. I hope we can do this with more IST queues. We can discuss needs and explore possibilities with groups and permissions and also explore in RT4.4. We need to make sure that we don’t allow viewing of tickets in confidential queues (e.g. HR) to all of CSCF, because a ticket is requested by someone in CS.
            2. Ideas
               1. Open IST-* queues for IT staff on campus
               2. Dashboard sent to IT staff of all tickets created by anyone in CS or Math
               3. Explore roles
         4. iv. Time tracking with tickets that are collaborated on between CS staff and potentially IST staff
            1. Process details and exploration
            2. Ideas
               1. Have ppl put comment or reply in with the amount of time worked at the same time THEN talk to BP re: how to pull this out based on date and summarize by person: list of tickets that shows time worked by that person within each week
2. Ticket roles
3. If time, also see: https://cs.uwaterloo.ca/twiki/view/CF/STToRTInvestigationFactorsAssessment
4. Discuss what may require development/investigation
   1. High priority but not required for go live
      1. i. How might batch-dependency creation work? can RT create dependencies via email? (I see in your latest notes you've mentioned "search then batch update" - maybe we will want to see that in operation). GOAL: not merely to record a collection of dependencies that already exist, but to automatically create a collection of dependencies.
         1. AND/OR create a standard set of ticket at once (Master ticket and multiple dependent/refer to ticket)
         2. Ideas: RT form tool, Approvals
5. Required to go live
   1. i. Time tracking with tickets that are collaborated on between CS staff and potentially IST staff
      1. Process details and exploration
      2. Ideas
         1. Have ppl put comment or reply in with the amount of time worked at the same time –CSCF already does it only this way (via comment/reply)
            1. i. THEN talk to BP (Search options) or John Kemp (MS BI) or internal script that generates email or ??? re: how to pull this out based on date and summarize by person: list of tickets that shows time worked by that person within each week and send report to CSCF or MFCF manager
            2. Review RT 4.4. question for consultants relating to critical factors and features
               1. Review list in 2. above
               2. Winter planning
                  1. Training
                  2. Configure 4.4 as needed
                  3. Finish migration plan
                  4. … more needed here
                  5. May go live

NOTES

Ticket Roles – notes from MFCF/CSCF

Often for simpler requests the responsible person is the same as the owner.

When they are different, the difference is that the responsible person is where the buck stops -- making sure the work happens, but not actually doing the work. The work is done by the owner(s).

Responsible:

The "Responsible" field in a work request identifies the single entity that is responsible for resolving the request. It is either a UW userid, or an e-mail address of another work tracking system, typically "request@ist".

Owner:

The "Owner" field in a work request identifies who (or what) is doing the work to resolve the request. An owner is either a UW userid, or an e-mail address of another work tracking system, typically "request@ist".

• Could add new role called ‘Responsible’ (or ‘Point of contact’) that only applies to MFCF queues (if needed)

AdminCC role could be ‘second, third etc.’ owner …OR a new role called ‘backup-owner’ could be created

The "Admin CC" field in a service record identifies who wishes to monitor the work, by receiving the same generated email that the owner does, and by having the same access to the record that the owner does. This is typically someone in a supervisory or management role.

Critical Factors and Features

*see also: Reference: https://cs.uwaterloo.ca/twiki/view/CF/STToRTInvestigationFactors *

• We need a smooth process for making improvements to the software, whether it's in order to add or modify features, or in order to accommodate our workflow (including changes we make to our workflow to meet our client needs).

• Dev server to develop/test
• Turnaround time if IST needs to make the changes on live server
• Explore ability to distribute admistration based on types of changes

• We need prompt updates about planned changes to the software that are outside of our control.

• Already in place, CM plan

• Feature: tracking time spent, with a convenient interface (ie, not editing the total time worked)

• Process: Actions/Comment, enter time worked (and comments optionally) OR use built in timer feature within ticket (click on small clock icon to initiate)

• Feature: ability to view all tickets in queue, not just ones you're involved with

• Can be done based on permissions – read only mode for a group of users, etc.

• Feature: Item dependencies and see-also

• Built in
  • Child/parent
  • Refers to referred by
  • Depends on, depended on by

• Feature: Ability to update tickets via email

• Comments/replies: built in
• Modify status, subject, etc: a plug in exists that can be explored

• Feature: Attachments to related documentation- uploading files, as well as links to private/public files.

• Attachments: yes
• Links to private/public files:
  • can be added in the ‘Refers to’ Link
  • (OR: could create Custom Field for this – may not be best but up to department etc.)

• Feature: Auto lookup barcodes in inventory and hostnames in inventory and DNS, fill in corresponding info and room number, warn on typos, canonicalize hostnames, link barcodes and hostnames to inventory

• Custom java script development would be required and would utilize Custom Fields/Scripts

• Feature: Auto lookup users and email addresses, canonicalize, show real name, link to WatIAM, warn on typos

• Included – except non ‘warn on typos’ yet
  • In request forms or when replying to a ticket:
    • There is a way to validate requestor, etc. to ensure they exist in RT and show error message (call back feature)

• Feature: Handle simultaneous update by multiple users of multiple fields in the same request without locking or losing updates

• Would want to test this; all changes will be logged and last update to specific fields will likely be saved

• Feature: Sort search results by due date, date created, or last acted (or any field displayed)

• Included in search feature, improved with 4.4

• Feature: Arbitrary SQL searches (e.g. date_created>unix_timestamp()-3600*24*7 and subject like '%print%') with ability to bookmark and API (e.g. needed for Bill's run-on sentence)

• Would need to explore

Important Factors and Features

• We'd like to collaborate with IST and other RT stakeholders to implement an RT-connected Knowledge Base

• Can do this

• Feature: batch dependency creation with particular fields set to arbitrary values

• Do a search then batch update may meet this need

• Feature: flexible search; if possible, ability to include SQL (eg., Fraser will fine-tune search query with SQL wildcards such as "evergreen%MC%3007")

• Advanced search will likely meet this need in Search builder

• Feature: API so our inventory system can continue to report on related work items

• Should be doable

• Feature: custom field, for subscription code, that we can easily extract work-hours on particular codes, and replicate the ST functionality within the "subscriptions" database.

• Need more detail; likely possible

• Feature: recording data to allow budgeting / managing spending using cost-estimate (and keywords and dependency trees - such as summing cost-estimates including dependencies)

• ‘Time Worked’ field does this; would need to explore for Time Estimated; would need to review

• Feature: direct access to the uploaded attachments, eg., smbmount

• Not available due to permissions on queues/tickets

• Feature: Arbitrary choice of columns and their order and optional abbreviation in search results with ability to bookmark and API

• Yes, available in search builder

Nice-to-have Factors and Features

Feature: command-line access to perform searches and updates

Available ..would need to review

-- DanielAllen - 2016-12-02