2023-10-19 Metadata Management Meeting notes

Charlotte Whitt 

Felix Hemme 

Craig McNally 

VBar 

Craig and Vince will attend the meeting to discuss and answer any questions that may arise.

All: Please watch the recording in advance:

• Link to the recording: https://prod-zoom-recordings-openlibraryfoundation-org.s3.amazonaws.com/276819cf-e9a6-4071-b72f-3bfb01131bbc%2Fshared_screen_with_speaker_view(CC).mp4
• Link to the chat: https://prod-zoom-recordings-openlibraryfoundation-org.s3.amazonaws.com/276819cf-e9a6-4071-b72f-3bfb01131bbc%2Fchat_file.txt
• Link to the PC meeting minutes: 2023-09-14 Product Council Agenda and Meeting Notes

Related WolfCon23 slidedecks

• Applications And The Management Thereof
• Folio Platforms
• 2023 WOLFcon Architectural Blueprint

My unsorted questions (Felix) : (responses in italics)

1. Applications:
   1. Slide 9: Are there any disadvantages when several BE modules use the same storage? Would there be an advantage, e.g. better performance for read/write accesses? Downside: Is this a violation of modularity?
      1. yes, there are some risks; main problem is with modules making "write" operations into same storage tables
      2. expected there will be coordination between modules,
      3. being able to read data in shared database is the main advantage (without having to make joins, pull large amounts of data)
      4. currently same module writing from 2 different apis also has same risks
   2. Slide 10: Merge mod-inventory and mod-inventory-storage into one module? What are the advantages and disadvantages of this?
      1.  simplicity, streamlining of data flow
      2. revisiting "source of truth" approach; currently, Inventory stores items, item status source of truth is thus in Inventory even for circulation or ordering workflows
      3. thinking in terms of applications & boundaries–for example we could create a streamlined item in circulation domain (think of it as a "circulation item") that would store the circulation status (and be source of truth for that element)
      4. ability to go beyond CRUD apis, e.g., execution type apis, which are currently limited by large data sets that are pulled
      5. helps streamline release process
      6. original motivation for separating mod-inventory from mod-inventory storage was not to tie users to a single storage layer; but this has not panned out, we have settled on postgres, so separation between business logic and storage is not necessary (and is not the model for other more recent modules)
      7. opportunity to re-imagine how the pieces fit together now that the entire platform is more mature
   3. Slide 11: Independent application development lifecycles. How exactly is this supposed to work? As I understand it, the flower release is also intended to check the interaction between what Vince calls applications. Not only the interaction of BE/FE modules inside one application.
      1. metaphor: cellphone or operating system; you get certain regular operating releases of the OS, along with those come distribution of applications; but once you have your browser, you don't have to wait for a new OS release to get an updated version of the browser (e.g., Firefox can be updated separately and will be compatible with multiple versions of the operating system), though some applications would require the operating system to be updated
      2. applications would be qualified against a version, i.e., flower release, of FOLIO
      3. inter-application dependencies are one of the challenges; these dependencies need to be reduced in order for this to work
      4. breaking up in applications and reducing dependencies would need to be done incrementally
   4. how would this who process be distributed? applicable for an existing tenant?
      1. a new release would be similar to how it is now, with new versions of applications
      2. but applications could also be updated independently of, i.e., in between updates of, the version upgrades
      3. upgrade scripts currently exist and would need be adapted, including providing info about compatibility with dependent applications
2. Platform:
   1. Slide 16: I understand Core+Functional to be like the iOS operating system and the Extended part are like applications I can install from the App Store. Would that be a reasonable analogy?
      1. it's an interesting analogy – bottom 2 tiers (core and functional) are equivalent to the operating system plus applications built in to the distribution (key set of applications needed to fulfill functionality); on top of that anyone can install additional applications, which are analogous to the top tier (extended)
      2. many applications intended to interact with external systems are not needed by all users, thus could be extended rather than distributed to all users
      3. flower releases could be limited to the most common applications
   2. Slide 18: Example ERM: The local KB is part of the Agreements modules, but is not used by the US libraries. How should something like this be handled? You can't simply separate the pieces (AFAIK).
      1. ERM modules now are able to function with or without the local KB
      2. a decision would have to be made for each platform; definition of platform can be adjusted based on needs
   3. Can one switch from one platform to another, e.g. ERM platform first, then ERM+acquisition platform? Or would one start with ERM platform, stay on it and install the acquisition apps afterwards (as extended)?
      1. yes (answered in presentation)
   4. Who decides which application belongs in Functional or Extended when it is in dispute?
      1. this is product definition, so this should be up to PC
      2. how many products does the PC then need to manage? this will bring up some governance questions that will need to be decided, e.g., are there other groups making decisions about other platforms w/PC deciding about the LSP platform
      3. a separate community could choose to create & manage a different platform

Questions by Former user (Deleted) 

Who will decide in general (not only when in dispute) which Apps are "common sense" and must be included in "Functional"? What will be the criteria for this decision?

commonality of usage will likely drive which applications belong in "functional"

breaking up Inventory will likely be guided by logical purpose, scope of material being managed

easier to manage definitions with smaller number of applications rather than large number of modules

Who will take the responsibility for the "Extended" Apps and that they are capable of running throughout all platforms and all releases and that they are interacting with other apps properly?

good question; responsibility falls on developers of apps – this is implicitly what happens already with modules, e.g., POs insure regression testing

recommendation is that applications are managed by a single team in order to ensure coordination among modules

PC update

Charlotte Whitt 

2023-10-19 Product Council Agenda and Meeting Notes

Announcements:

New procedure for SIG reporting - SIG Reports 2023-10-19 (note: this places more of a burden on liaisons)

CC (The Community Council) will reduce it's number of members. 

Now: The council will have 15 members but can operate with a minimum of 9. The council will seek to have a diverse membership.
Proposed replacement: The community council will have 13 members but can operate with a minimum of 7. The council will seek to have a diverse membership.

Current state of FOLIO Quality Assurance testing - presenter: Yogesh Kumar, and Oleksii Petrenko. Link to slidedeck here (when available)

Testing methodology: In Sprint Testing by development teams and Release testing (Bugfest - 3000+ testrail cases)

Example of a UAT survey (Poppy, 2023)

Definitions of Smoke test, Critical path, and Extended 

Release planning:

Release roadmap/time line - e.g. Poppy.

Follow up on Re-architecting Impact on the Product Council report: Link to the report here. And then this topic is the main topic here at today's MM-SIG meeting.

The PC recognises that the current flower releases are problematic, and the PC are endorsing that the community is going ahead discussing how to implement new definition of applications and platforms, but a further discussion in the tri-council group is necessary, and the PC will suggest check ins around mile stones, to make sure that that stakeholders are being involved, and that re-definition of applications and platforms are not causing new problems.