Date
...
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 | |
Notes
Fixed due dates and renewals (Sean):
...
When an item has a request on it and goes in transit to a pickup library, what information do we need on the modal? Currently, the modal does not indicate there is a request, but simply says to route to <library X>. Cate said that to include additional information would require considerably more programming. Is this piece of information was necessary? The Five Colleges do need this because of their work flow (they also need the actual patron information); most other libraries felt that having a statement that the item had a request would be helpful, at minimum. Cate asked if it would be enough to have the requestor information print out on the routing slip? Five Colleges: no, since they don’t print the slips; William, no, because of privacy concerns in a public-facing workstation; Susan and Andrea, no, because they must have the information before the routing slip is printed; Cornell does not need patron information on the modal, or even the fact that there is a request, because all in-transit processing goes through the same channel; but it would not hurt to have it. Cate concluded that we may need an additional in-transit modal for items with holds – save for future discussion