Problem Reporting/Tracking
Gather common data
- 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
Solving and Responding to Problems
Access to each others systems and information
- 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
Common responses and procedures - wiki?
- Get current information organized in similar way
- Merge as appropriate and/or create common dashboard
- Proper permissions for access
- Any vocabulary to sort out? Uni/NetID
All staff looking at each others issues - milestone - how long does this need to go on before we move to next phase?
- 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
- Union issues?
- Privacy issues? includes staff - are we violating any privacy concerns at each institution; also includes any third party systems we might use for tracking - can we purge/anonymize patron data
- Vendors working with one CUL on the other's behalf, i.e. we're no their "contact of record"