| 30 min | reference record upgrades | | - There has been a lot of discussion, but little consensus, on this topic.
- Two approaches to review
- Problem statement in a nutshell: sysops notes problems WRT FOLIO upgrades and customizations being made to system-provided data. Institutions want to get new ref data that comes with an upgrade while preserving their customizations. Details.
- separate default/ref data from operational data. two approaches:
- Proposal A: add extra fields in the record, allowing customizations to take precedence
- Proposal B: system/default data as totally isolated from operational data in a separate table space; system data takes precedency
- there is an impasse here but need to identify next steps.
- Pain points: need to have upgrades go smoothly and have end-to-end automation, i.e. no manual intervention. Customization of datasets makes this difficult if not done carefully.
- Proposal A: goal in keeping things together is to identify overridable attributes, make it clear what is shared, what is changing. Details. e.g. inventory material types: clear that customizations will be necessary. Being explicit about what is system-supplied vs what is local makes the upgrade process more explainable. This is a customization-centric approach.
- Mark Veksler : what about i18n of dynamic data? Zak Burke : important, but separate
- Proposal B: Two pass process:
- Apply changes to existing default data.
- Look for conflicts/overlap among default data, custom data. Allow for manual reconciliation.
- md331 (Deactivated) Is there any dry-run possibility, i.e. the ability to write the reports without actually making the changes? VBar: No; but could run these scripts against a shadow system; this seems to be de facto practice among sys-ops.
- Desire: automate what is unambiguous and call out what is in order to report on it.
- Jeremy Huff: overhead of upgrades is determining scope of the changes. What about using tools like GitHub to manage diffs? There is an expectation among SMEs that they can make changes to some values.
- Main conclusion of working group's work: there are separate datasets that need to be reconciled
- Goal in bringing this to the TC: pick one for a POC
- Concerns: how to scope this work to keep it small, how to assign a group to do the work?
- md331 (Deactivated): can we go to users/sys-ops before sinking the time into a specific POC?
- multiple user classes here:
- devops doing upgrades
- SMEs doing data customization
- what about a new small group with fresh eyes taking this forward?
- Mark Veksler Who will drive requirements for POC?
- need a sysop representative
- two spikes:
- define steps necessary for POC
- do the work
- timebox this to just a few sprints to keep the scope small
|
| 5 min | future agenda items |
| Reference record upgrades: There was a lot of discussion but no consensus about precisely what the next steps should be. We agree there should be a POC but we need to figure out resources, time commitments, and desired outcomes. Take < 15 minutes next week to solidify the plan. |