Versions Compared

Old Version 17

changes.mady.by.user Lynne Fors

Saved on

compared with

New Version 18

changes.mady.by.user Laura E Daniels

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

Announcements

Charlotte Whitt 

Felix Hemme 

Bugfest testrail tickets. As of today 37% testcases are unclaimed. So please, please claim test cases if you are involved in the Bugfest test. Bugfest test will start on Monday 10/23/2023 - 11/3/2023 (Friday).

Poppy UAT for the following features:

  • Inventory advanced search modal
  • Creating original MARC bib records from UI
  • Authority control (automated and manual linking)

The form is open until the end of 10/19/23 (TODAY!)

overview of the re-architecting proposal

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:

Related WolfCon23 slidedecks

My unsorted questions (Felix):

  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



to be incorporated into the above?

As Inventory is central, what are potential impacts?

reduction of dependencies & refactoring Inventory into smaller, more independent pieces would make it less central

How will we in the future be able to trouble shoot bugs which we first identify in the local implementations - if we don’t have a well understood release like the flower release, and can compare with the reference environment for that given release. (from perspective of support SIG, investigating issues reported from libraries, who are using different versions, configurations, settings, etc.)

process would remain the same–need to reproduce a bug; so reporting it would need to include the release version & applications so that environment could be replicated to try to reproduce

changes to testing process



Charlotte: re slide 9 – thinking about permissions, right now very granular

how would permissions management change?

still have modules, but creating a layer above that (hierarchically), so module permissions would still exist

the application is comprised of a set of modules with same granularity of permissions

variety of types of libraries that have implemented thus far, with different models for "source of truth" in Inventory; how does this model impact, for example, the current model for those libraries using a union catalog as source of truth?

source record storage would be a separate application from Inventory, so no one would be forced to use it as source of truth

dependencies between existing modules make combination into applications very obvious in some cases (e.g., Acquisitions); but Inventory is a different animal – it's not a question of combining as it's already "a monster" application; Inventory needs to be broken up into smaller applications

Inventory currently both manages cataloging and serves a more literal inventory role

Breaking it up would allow institutions to be more selective about which aspects of Inventory they use (e.g., could choose not to use the cataloging aspects)









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.

...