2019-06-20 Resource Access Meeting Notes

Capacity planning assignment: Product owners will walk SIG through features, making sure that we have a shared understanding of features & that rankings are accurate. Answer the question: What are the core functions that we really need? And what can wait? 
Walkthroughs will be announced beforehand so institutions can make sure to be represented at the meeting that. Alternatives if people miss: watch recording, or review revisions through product council rep.
After walkthrough and ranking revisions, revisions will be passed to PC, who will set priority when there are hard decisions to be made.

Goal is to come up with a market-viable product for June 2020, so that 4-5 institutions can be running FOLIO next summer. 

SIG reviews features & rankings → capacity planning team assesses feature prioritization → product council makes final decision about what will be in the market-viable product. 

Other needs from the community: product owners, technical writers, QA & testing. Institutions that will go live need to begin migration activities. 

Notes from FOLIO F2F: https://docs.google.com/document/d/1uhMMFDMMMckC2r946j89ECb0j0HwssOCCsmKCqMgkIs/edit

Users and Inventory were considered from a circulation perspective

Card-sorting exercises are or will be conducted for both Users and Inventory

Intense conversation around Inventory - circ-focused view of Inventory would not just involve UI changes to the item record, but also prioritizing items over instances. May have an impact on search results & how those are retrieved and displayed. 

Notes from FOLIO F2F: https://docs.google.com/document/d/1uhMMFDMMMckC2r946j89ECb0j0HwssOCCsmKCqMgkIs/edit

Bulk send: avoid using the system during peak hours so that sending thousands (or hundreds of thousands) of notices doesn't interfere with other operations

Case to remember: borrower with 300 items all due at the same time, or all within a few minutes or seconds of each other, does not get 300 notices - they get 1 notice for 300 items.

What happens if the system runs out of idle time to send the notices? Can't spill over  into the next period (if a notice is intended to go out X days before Y date, cannot wait until X-1 days before Y date).

Idle time is usually during early morning (1am - 7am was one example)

Because multiple scheduled jobs may occur during the idle time, may have to have a place to schedule when particular jobs run.

Are there any users who aren't requesters ? Maybe proxies, and also staff workflow requests

For paging slips, distinguish between paging for patron needs & staff workflow needs

Tokens for slips: have been discussing mostly in context of transit/request slips, but no need to narrow that list  for other contexts.

Do we need the system ID as a token ? No.