|Product Council Update|
Peter brought a proposal for a FOLIO project code of conduct. It is in draft form. This is based on Islandora's and Code4Lib code of conducts. They want a code focused on what we want the community to be. Please take a look at the draft and post comments. A small group will be convened and then present the draft to the community. This could be part of the opening session at WOLFCON. Peter is also seeking community support volunteers to deal with reports and articulate reporting guidelines.
We can hire a technical editor (writer). This is the documentation tzar. There will also be a security audit from the same sponsor. They hope to have documentation out as soon as possible, early 2020 for the community to review. This will be commercial grade documentation for users and developers.
Presentation from Tech Council: https://wiki.folio.org/x/a6Dc
Chalmers is in the midst of their migration, staff training and planning. There will be a future forum hopefully in January. There will be a demo in the next ERM SIG meeting. Dracine will ask about ERM and documentation. Chalmers is a unique implementation given their relationship with their national library, ability to do linked data, no MARC, no finances, etc. Where can we put documentation that people are beginning to create? The FOLIO implementers group has taken on the task of wrangling documentation. This was a chance to test the fulfillment workflow.
FOLIO Bugfest testers: Around 64 people signed up to be testers. Chalmers also wrote a lot for their tests. People could follow those if we have access to it.
Capacity Planning Team will coordinate with institutions where soon after these institutions will decide on go live or not.
|Peter Murray||Volunteers needed for FOLIO Community code of conduct.|
|Subgroup Updates and Other Updates|
ERM: presentation from Chalmers (10 minutes) on Sep 11 in the ERM Sub Group. Meeting times see https://wiki.folio.org/x/wol3
Data Import: AM working with designers to finalize more designs. Work on the mapping has been refined with things like the index title or call numbers.
Data Export: The first meeting is today.
Container: This has been wrapped up. The mock-ups are done. This is NOT cap MVP. The group came up with a list of paired down elements to get these implemented first if there was capacity.
|Feature ranking/new features?|
|Call number search, sort, display update||Laura Wright|
Progress report on
Feedback (particularly in the form of user stories!) welcome
This is in progress. The linked feature has comments and a link to the document with notes from the meetings. Please have a look and provide comments. Looking for user stories in the next week or so.
|Inventory Permissions (Basic CRUD)||Charlotte Whitt|
Following stories are in Jira:
For Inventory, there is a capture ALL for functionality and then there are defined permissions for each of the settings pages. This is work for the MVP and implementing the basic CRUD (see UXPROD-1371 above for more details). All records with an underlying MARC SRS bib all have the restriction of being able to edited in MARCcat and not in Inventory; this only applies to fields maintained in MARC. Permissions for all apps have been written over quite some time but will follow the wording of permissions by organizations. Charlotte will be doing an update to align wording. The only blocker is the ability to delete an instance. Further input is needed on deleting records. Deletion can be tricky if there are order records attached or items. We should be able to do this as we can do it now in our systems. We should have deletion in both apps (Inventory/MARCcat). MARCcat isn't necessarily aware of holdings and items. Would you need a check? MARCcat should be aware of the instance record. Ideally MARCcat should do a check for attached records. This can be brought to the MARCcat subgroup. We need to think of this more broadly in terms of any SRS storage to have the same process for deletions. There are many scenarios for why you need to delete records (bad batch loads, duplicates, etc.). If we delete from one place, should we delete from Inventory? We should be able to delete in Inventory. Initiating the deletion in Inventory is a good idea as long as there are the checks and balances for all associated records. With that in mind, for many batch loads, deletion starts with the SRS MARC bib. Chicago is planning on moving administrative data to holdings and item level and get it out of the MARC bib. This may be a policy and/or permissions issue. Batch deletion is critical for Chicago. There's the functionality of "mark for deletion". Data Import does not have permissions set up and there is no deletion set up currently. The permissions have to hook to each other. Are there permissions to access the data import app? There should be an "on/off" setting for Data Import App. This could be a permissions concern if at go-live individual records from OCLC need to be imported. Would it make sense to review permissions across apps in a couple of weeks? Q: Have seen that permissions have different tier options? For all apps, can all the tiers be made coherent? Can the levels be the same across all apps? For example, can we have all as an option? One idea is to move away from using tiers with numbers. Institutions can create sets such as student worker 1, or 2. SRS will talk to the discovery layer. There is the suppress from discovery. Once it is deleted from Inventory, it needs to be deleted from MARCcat; this is the sync. If there are instance records that don't have a SRS record, then a MARC record on the fly created via OAI-PMH.
|Future meeting topics|
Source of truth (SRS). Review the FOLIO metadata flow based on test of the newly implementation of edit freeze of records in Inventory when having only SRS and Inventory installed.
Inventory Permissions (
Search enhancements - possible also look at more general requirements for defining search, e.g. when to use: Phrase search, Truncating (left and/or right), Stemming, Nested search, Boolean search, etc. (TC and MM task)
Authority Data and Inventory Vision (small group work first)
Discovery – need to clarify sources of data for discovery vs. data needed for operations; this needs to be documented for the entire FOLIO community and direction should come from Product Counil
Item record statuses and the apps that affect them
Music / Maps / Media cataloging review of data elements in Inventory
Felix (via chat) "@charlotte: I could ask a colleague (from one of the 180 network libraries) if she/he could review the beta elements from a 'musical' point of view."
Texas A&M may have a music cataloger that can help.
Christie offered to load cartographic and music data from other libraries into their test FOLIO instance.
Jennifer (via chat): We should also look at video as well. Videos have other standard numbers EAN for instance and fields that people like to search and discovery them by