Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Comparable forms which are set to gather common data
    OR
  • Separate email aliases, as we have now, which are set to push email to a common tracking system.  The tracking system would then ideally give IP, DNS, Browser/OS, Referring URL.  Are most tracking systems set up to be able to get this information, or will we need to use a form to gather the data and send it along to a tracking system. 
  • If permissions are not sent to the tracking system, we may need a procedure to look them up.
  • Cornell is revamping "feedback" forms as part of Discovery & access initiative.  Opportunity to influence what is gathered from users here as most "feedback" is a troubleshooting issue.  How to handle non-affiliated users?

How do we ingest and manage issue reports?

  • Ingest problem into common tracking system (e-mails or actual issue management system)
    • Pros/cons of options
    • Decision to pilot X?
      • Proposal to Steering
      • What variables to account for: number of user accounts, desired premium features,...
    • How did X work?  What needs to be changed?  Should we try a different system or will X work?
    • Auto-response, excluding personal details and/or copying others
    • Database?
    • Ability to attach screenshots - during initial submission and as parts of responses
  • What changes at each CUL required?  i.e. Cornell does not gather some of the user info that Columbia does via form.
    • What info is most useful or essential?  IP/DNS, patron permissions?, Browser?, Referring page

...

  • Ordering/Payment info - Voyager, EBSCOnet, etc.
  • ERMs
  • Access to one another's e-resources from "on-campus" (VPN) and "off-campus" (remotely) -
    • Our work is considered "doing the business of XXX University"? Right?
  • Is there a need to inform vendors that this group may be working on each others issues?
  • Will remote desktop cover Voyager access well enough?   Is there something better?

Begin joint troubleshooting on (goal:Spring 2014) - Target Date: XX/XX

  • Common types of issues:
    • Site down/deficient
    • Site requires particular action or browser
    • Browser problem
    • Payment problem
    • EZ-Proxy
    • URL changes
    • Abuse/excessive downloading
    • User permissions and exceptions - does user have valid permissions?  Is there some other block on their NetID/Uni?
  • Policy vs. Technology workflow decisions?
  • What issues immediately go to home institution?  this list needs to be well-defined, as it can cause political headaches if handled incorrectly
  • What can be handled jointly?
  • What must wait until X system is better integrated?
  • Need to assign point people at each institution to take questions from staff if we run into gray areas about who handles what problems - who and how to escalate or route.
  • Define schedule

Training and Transition

...

  • Period of training/adjustment for each CUL as staff adjust to the new tracking systems. (This is a public service; it should be done well!)
  • Able to respond to each others lists & assign issues within the tracking system.

Phases

  • Team looking at reports - currently happening
  • Team responding to lists/each other, if they have useful input - currently happening
  • Team researching and responding to issues - next step
    • Look for - do we have access to the right information, does that access work well?
  • Repeat these steps with broader troubleshooting staff -

Possible Issues to Address

...