2019-2-11 Resource Access Meeting Notes

We're going to hold off on Thursday meetings for the next couple of weeks while our POs finish up with their push for Q1. Please leave them on your calendars, because they'll be back.

- Should recall requests automatically go to the top of the queue (probably below rush recalls, when we have them) behind any existing recall requests?
- What happens if the request queue is manually re-ordered and a hold is put above a recall in the queue?

- Considerations:

-- We've said renewals should be blocked on items that have been recalled - do we only look to see if a recall is in position 1 of the queue or should we block renewals if there is a recall anywhere in the queue?
-- What about shortening of the loan period that usually occurs when an item has been recalled (based on the recall return interval and minimum guaranteed loan period)? Do we only do this when the request in position 1 of the queue is a recall?
- Current thinking is that only looking at position 1 of the queue is the simplest and most understandable
- What use cases should we consider?
-- A request was originally created as a hold but is now more urgent.
-- A request was originally created as a recall but is now less urgent.
-- Other uses cases? What are the use cases for manual request queue re-ordering?  

• Because...
• Because...