2021-02-25 Metadata Management Meeting notes

Agenda/Notes

• Will need to identity how the MM SIG can help Charlotte
• will hope to catch bugs earlier, before bugfest, and this is cheaper to fix
• the whole bugfest race will start again, right after the previous bugfest race
  • so, trying to balance out that rate of bugtesting between bugfests
  • expecting more testcases and more specific and granular testcases then for bugfest would result
  • This new bugtesting process will get more people into the weeds in FOLIO
• Wondered if a specific person would take on a role for a timeframe to help this bugtesting process (not casual, very important)
• from chat (

  We did the writeup of testcases early in the beginning of the ERM project. It was a good way to get familiar with the app and find strange behavior)

• Core functional team capacity
  • diminished starting soon
  • FOLIO needs more developers
  • they do dev for Inventory and many other apps
  • for instance, results enhancements may get slowed
  • Are there ways to contribute needs, is there an easy way to contribute code back to FOLIO?
    • WolfCON topic?
    • it needs to be easier for local devs to contribute CODE to FOLIO (as opposed to just using the local code for local needs, but that could be helpful in a wider community)
    • comment: (the project should not have to rewrite the code all new if a local institution has made something that could be contributed back
    • Attempting to think about the issue of limits in programmer resources
    • There is a survey about this, but this issue just needs to be continually raised
    • some folks are making local things because they have come to expect that the FOLIO contribution plan and portal is not easy or clear
    • Comment: the code and community could be more robust if the local contributions could be added easily
    • But there is always a balance between local staff time for local work and larger FOLIO code contribution (which helps the whole project)
    • Even when institutions come together and make funds available, this process takes a LONG time
    • from chat (It is quicker to develop locally. )
    • folks are getting frustrated
      • we need a faster turn around
  • cofunctional
    • working on different scenarios

Laura E Daniels

Christie Thomas

Conversation continued from last week's meeting

In case it helps, the definition of reference data is: Data that are referred to by other records in the system (see: https://folio-org.atlassian.net/wiki/x/3YNW and https://folio-org.atlassian.net/wiki/x/NBZN for more information)

Documentation of current implementation

To Do Today:

Document specific examples for developers: e.g., how we would like to be able to customize reference data (adding, deleting, changing)

Google doc for working draft (Laura will turn this into a wiki page if appropriate)

notes:

Documentation of current implementation:

• • Expectation that reference data will move to Entity management app
  • Questions about reference data and choices about it (or them)  
    • Classification label: LC, but some may want to spell this out: Library of Congress Classification
    • NLM is not spelled out, but national Agriculture library is spelled out
    • inconsistent in the reference data
    • Will labels need to changed every time FOLIO upgrades
    • default data needs to be made more consistent 
    • Can labels be changed in reference data?
      • Charlotte comment:
        • if labels need to be changed, then they should be corrected in the right way in the reference data
        • also, keep in mind, different data sources and contexts
      • AM comment from chat (And speaking of defaults - maybe useful for this conversation - a new instance identifier type of Cancelled system control number - what are the implications? )
      • from chat (I also want to know about deletes - if we delete a FOLIO reference data value does it come back at the time of upgrade?  / / If we want a different label should we make a local value rather than changing the FOLIO reference data label so that it is not impacted at upgrade? )
      • current upgrade behaviour for reference data: narrowly defined by tenant-load reference data = true
        • all data defined as reference data, system attempts tp create and update with the current valued in the module, if that fails, the upgrade would fail... (please clarify this part
        • If you tell your sys lib to load reference data...
          • please feel free to update this above part about reference data and upgrades by someone who understands it better.
        • Question from CT in chat (Is the reference data update all or nothing? For instance, some areas are okay to update, such as those that are managed by external vocabularies, but there are some that are definitely all local - such as instance status. )
        • Answer from chat from Wayne S (

          Currently it is all or nothing.)

        • Discussion to the group about how it works, or how it ideally should work?
          • both
          • from CT in chat (Definitely both. Right now we need to know how to manage our data at go live and then we need to make it better for long term management of the data. )
          • from chat (I’m guessing a change to how it works is a long road. So I definitely want to know how it works now and how we can mitigate this system to work for us now. )
          • from chat (Yes - biggest question seems to be - how do I keep local customization, but also get (or at least be aware of) the new central/default data )
          • we don't want to overwrite local data
          • from chat (We do this with our cataloguing records—we must be able to do this with our reference data? )
          • we need plenty of local data
          • we should not have to manage all the reference data manually
          • from chat (I agree with christie. I’d rather talk about what’s going on now. The future is a longer term conversation. We need to know what to do now.)
          • what is Marc and Wayne's recommendation be for libraries going live in 2021
            • would want to have this conversation with a local sys librarian
            • one strategy would be to have an extraction of ref data and in a test upgrade, load the new data and compare
            • not automated
            • from CT in Chat (That is something that we need to know, too. When does a reference data change require an update to the marc to instance map. )
            • from chat (Can’t the installer look at the data and only replace if old default is in place. If custom value is there then move on) - answer: currently, this is NOT available now, but could easily be in the future - and new terms should be accepted, not the ones that overwrite local terms
            • AM: wrestling with this from a data-import perspective
              • don't want to overwrite local stuff with the data-import 
            • the system may need to 'know' a local institution has custom data
              • but does not at this point
            • probably safer to not load new system defined data when they upgrade
            • from chat (Installations should have a choice at upgrade and for each upgrade. One - replace all to new defaults. Two - keep customizations. Three - we want to customize the install for specific changes. )
            • Still would be useful to write up what MM SMEs desire to be the long-term behaviour
              • yes from devs 
              • want the specific analysis of what the behavior is (or desired), not opinions on how to fix the issue

Felix Hemme

Theodor Tolstoy