Date
Zoom
Attendees
@Eileen Cravedi
Discussion Items
Time | Item | Who | Description | Goals/Info/notes |
---|---|---|---|---|
2min | Administrivia | Cancelling the 2021-07-05 meeting ? ------ Bugfest June 28, Monday to July 9, Friday Info here: Bug Fest R2 2021 Juniper |
| |
10 Min | Check-in respons times | (via Slack in #ressource-access) Looks like I didn't ask about check-ins/check-outs, but Cate did. Please go to the "Performance" tab of the spreadsheet at https://docs.google.com/spreadsheets/d/1oa5PnM9HqbKQl1lAe08aKojz29Go_-amQCNiMzwPnZc/edit?usp=sharing. The expectation is that it will take less than 1 second. At Cornell is painfully aware, we aren't there yet. I have created two Spike JIRA tickets for this and assigned them to the sprint that starts on Monday. The tickets are UICHKOUT-726 and UICHKIN-269. I have named Cornell and MO State as "Affected institutions". Other institutions should add themselves as needed. | ||
45 Min | Title level requests | Continued discussion and updates on TLR |
Meeting Notes (David Bottorff, notetaker)
- Response times for checkins and checkouts (Andy Horbal)
- What is the slowest you could tolerate
- Cornell 2-3 seconds every time for both in test system
- Jana-that would not be acceptable gbv
- Andy would you pull the plug?
- Cheryl I don’t think this would be acceptable
- David I don’t know that I could say that but would be loathe to go forward without a plan to reduce timing in short timeframe
- Erin pdf describing functions-can do 20 or more API calls at a time
- Erin thought process will be is this a business need or a staff expectation?
- Lehigh has consistently had a second or less
- Chalmers also faster has not measured
- Cheryl Cornell was real world testing with other actions happening
- Cheryl It becomes a problem if staff are doing the checkout, more of a problem with self service checkout
- Jana something to discuss further to our next meeting?
- Andy hit me up in chat or slack but having idea of consensus of what would be tolerable
- MO state is not regularly seeing >1 second unless doing data import or export
- Title Level Requests (Steph Buck)
- Mock-up combining into one queue
- This is most complex mock-up. Item and title level on same instance
- David do we need something to indicate when something is a title level request?
- Header “awaiting fulfillment” seems confusing to several.
- What about in progress? Confusing with in process?
- Could we move in transit to lower accordion?
- Andrea separate queue of awaiting pickup or delivery?
- Bottom list can be reordered. Top list cannot be reordered
- Assigned requests? For first accordion Marie
- Fulfillment in progress seems to be consensus - translation will work for GBV?
- David less concerned about language and more about the logic of what goes into each accordion. In transit would stay in top accordion
- Questions around title level paging workflow, and title level hold requests (would these appear in paging list?)
- Is there logic that weights things geographically or otherwise? item level logic in place at Chalmers
- eventually we would want some logic based automatic reordering. Also some flag for manual reordering so that automated reordering would not reset and bump something back down.
- David - also as we move away from requests for staff needs (reserves, preservation, etc. needed for) to determine whether staff needs trump patron requests or vice versa. Perhaps a flag in the staff request as to whether it trumps or not?
- position queue number in first accordion should match second accordion?
- Brooks - depends on perspective - title level is dynamic and changes things
- UI - could we get hold shelf expire date in first accordion?
- Will continue TLR discussion on June 28
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to supporting materials | Comments |
---|---|---|---|---|---|---|
e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |