...
Time | Item | Who | Notes |
---|---|---|---|
5 min | Announcements | None. | |
20 min | LDP App - clarifying the current state of this as there is some confusion. | Jesse | Mark Veksler posted this in the TC channel that looks like a good summary of the situation: https://folio-project.slack.com/archives/CAQ7L02PP/p1632849256366500 Mark's post: There is still some confusion over the outcome of TC's evaluation of the LDP app -- most recently it (the confusion) was surfaced in the Scrum of Scrums today. So, I'd like to recap (because there is an old Russian saying, "repetition is the mother of learning")
At this point in time, assuming the development team can meet the deadlines the LDP app will be released in Kiwi. There are some conditions that could cause the LDP app to be pull from future releases if not met. The assumption is that the LDP app will not be in the bugfest environment, but it can be tested in other environments (e.g. "folio-snapshot"). Tests for the LDP app will be in Testrail. Noted that this is an exception to TC's emerging process of including externally-developed apps; the code freeze for apps was last week, but development will continue on the LDP app past this date. The PC needs to create acceptance criteria as well. For instance, following the established style guides for the user interface.
|
20 min | Juniper upgrade slowness - https://issuesfolio-org.folioatlassian.orgnet/browse/MODINVSTOR-774 describes an issue that is causing Juniper upgrades to take a long time. We want to make sure PC is aware of this and see if we can come up with any recommendations for next steps or actions | Anya | Have a goal for migration scripts and set a standard for the overall amount of time it takes to upgrade to a new release. When moving from one release to another, data manipulation may be required (for instance, recalculation of totals). In the case of large tenants or multi-tenants, migrating the data can take a while (resulting in extended periods of downtime). These issues have not be recognized early in the past; product owners should be aware of this as part of the release criteria with the goal of reducing/eliminating downtime between releases. There needs to be a focus on optimizing the migration scripts as well as measuring the impact of the migration script as part of the release evaluation process. If libraries want the ability to skip releases, there should be a focus on establishing the Long-Term Support (LTS) release process for establishing a point where bug fixes will be back-ported. In this specific case, is there a desire to support an extra version because libraries will elect not to migrate to Juniper due to this issue? Noting that Cornell has developed their own off-line circ capability that they used during the migration to FOLIO and will likely use in the upgrade to Juniper. Missouri State Univ has also developed this capability. ("We use a shared spreadsheet and just process it manually. We don’t have volume to justify the development work to automate it.") Ian notes: "ByWater is interested in putting together an offline circ tool that's generic enough for the community to use; I'd love to collaborate with anyone who's already made progress on this." Notes from chat:
|
20 min | This item came from the last CC meeting: Action item: PC needs to keep a list of existing apps and their state of maintenance, their status of integration (tight or just loosely), developer team, responsibility, connected MoU's about maintenance . Can we assign this to a small group to get started. | Jesse | The Product Owners have created a Team vs module FOLIO Module/JIRA project-Team-PO-Dev Lead responsibility matrix. Harry is developing a simplified version on a single slide as well as a list of orphaned apps and modules. Having a list of orphaned areas is useful for when an organization joins FOLIO and wants to work on something. It is possible to have orphaned modules that don't in turn orphan an app (the single sign-on module is an example). There is another category of apps for which a team performs periodic maintenance but there is no active development (updating dependencies, for instance). An additional acceptance criteria for contributing code could be a memorandum-of-understanding to support the code for an explicit period of time. What is the maintenance commitment for code contributed by established partners? Assignment for PC members: take a look at the responsibility matrix and add a comment to the page (or send to Harry) by the next PC meeting. |
...