FOLIO Project Update – Week of June 25, 2018

The FOLIO Product Council was updated on the new OLE website and OLE templates are available with the new OLE logo. The gap analysis priority spreadsheet was completed by the early implementers; the data has been entered into JIRA and will be analyzed to scope the next releases. Reports from ALA and German Library Days were very positive, many questions were asked at sessions and there appears to be a lot of interest in FOLIO.

The Consortia SIG discussed the various use cases, workflows, and desired features around consortial union catalogs. FOLIO will not have a catalog layer, however, it is still important that the necessary data and functions needed by union catalogs are exposed via FOLIO API’s.

This week the Metadata Management SIG reviewed requirements for editing and storing holdings in both MARC and non-MARC formats. Their recommendations will be forwarded to the Product Council. The Batch Loader subgroup has identified over 100 sources of incoming data (bibliographic and acquisitions), and the MarcCat subgroup has begun meeting regularly.

The Reporting SIG reported that all first implementers but one need Data Warehouse at Go Live. A new requirement was added: the Reporting Tool must be able to integrate with the Data Warehouse. A new JIRA issue was created for the Data Warehouse (see UXPROD-945) and a new “REP” Epic category was created for Reporting. The Reporting SIG began to lay out the Data Warehouse design requirements.

The Sys Ops & Mgt SIG discussed a Lightweight Ticketing System vs. the ToDo App alias Workflow App. They then turned to defining action items which resulted from last week’s discussion about release management (a set of released code that does not change). They will need to build a system architecture guide. They figured out how to build a best practices guide.

The User Management SIG discussed the meaning/uses of the user “Status” field (active/inactive). It has been interpreted in practice as only applying to circulation eligibility, rather than more generally applying to user active status as originally specified. They also reviewed Duke’s needs for additional ID fields, and are fairly certain they can be accommodated by the existing fields and by custom fields in some cases.