Date
Attendees
...
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision | |||||||||||||||||
| Requests | Q2 | Display of open requests: SIG wants to see all requests on loan details regardless of whether they change due date or not. So, but is filed to fix the duplicate rows for recalls:
| ||||||||||||||||||
| Requests | TBD | Clearing hold shelf
| ||||||||||||||||||
| Requests | Short term hold shelf expiry periods Discuss short term hold shelf expiry periods - are they really needed? Use cases?
|
...
| Organization | Average Number Open Requests | Average Request Queue Length (number of open requests on a given item) | How Many Newly Expired and Cancelled Requests per Day | How Many Newly Expired and Cancelled Requests per Hour (assuming we keep the short-term expiry periods for reserve items, equipment etc) | |
|---|---|---|---|---|---|
| University Library Marburg | up to 1033 (2018-03-13) | about 130 requestsup to 1302 (2018-04-12) | per hour: about 29 | ||
| Cornell University | 244 requests placed per day (1 year average 4/10/2018 - 4/10/2019); current number of OPEN requests = 1,433 | 1.04 (current max=13) | Average per day: 13 cancelled; 29 expired; 202 charged | n/a | |
| Duke | Current number of open requests = 1,604 | ||||
| University Library Mainz | 820 current number of OPEN Requests (2019-04-09) up to 1200 (average per day) | n/a but: max. 3 on freehand area books / closed stack max. 5 on textbook collection | 46 (26 % of all requests) | n/a | |
| University of Chicago | current number of open requests = 1037 177 created daily | average 1+ max 8 | max 154 on a single day average 44 per day | n/a |
...
requests on loan details screen - do we want to display all requests or only those that impact due date?
yes we want all of the requests to show up as an action
also confirming that count of requests on item record takes you to list of all requests on item
clearing the hold shelf - cancelled and expired requests
original idea for expired was for request status and item status awaiting pickup by filtering
how do you come up with the complicated query logic for finding expired holds that need to be grabbed? logic is complicated by outstanding open requests
a new item status of "pickup expired" that is updated when request is expired or cancelled would simplify the discovery of these items
item status of "pickup expired" and necessary request info (patron name, barcode)
obviously need to limit by service point
report needs requestor, item barcode, title, item call number
assumption is that item state, etc. should be configurable at discovery layer level for display
Hold shelf expiry period can be specified in minutes and hours, is this needed?
the challenge is that the batch process or other query, how often does it need to happen?
Request Expiration Job
current implementation is that the system checks every hour, not a batch job (right now)
probably do need minutes/hours for reserves, equipment, etc.
need to do performance testing - estimates on average numbers posted as table, please contribute your institutions estimates
Chicago - 20-25% of requests expire or are cancelled
How many newly expired requests might there be per day