2021-09-30 Product Council Meeting notes

Owned by Jesse Koennecke
Last updated: Sep 30, 2021 by Peter Murray
5 min read

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
5 minAnnouncements

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")

  1. The PC asked the TC to evaluate whether the LDP app is technically compliant for inclusion in the Kiwi release
  2. Despite the lack of any identified urgency, the TC expedited the definition of inclusion criteria to accommodate this request -- a formalization of community established norms that have been in existence for ~2 years.
  3. The LDP app was formally reviewed, but failed to meet all the established criteria (as is required)
  4. However, the TC agreed to establish a one-time, limited set of acceptance criteria for provisional acceptance into Kiwi -- to be met by October 6
  5. The TC will confirm that the LDP app has met the limited set of criteria and deadline for provisional inclusion into Kiwi
  6. Provisional acceptance would only be for Kiwi, and the LDP app is expected to pass the full set of criteria to remain in Lotus
  7. Although the TC decided to extend a deadline, it is not actually within the TC's authority to establish release-related milestones -- it is the Capacity Planning's team responsibility.
  8. To avoid repeating this situation in the future, it is highly recommended that the Product Owner for the LDP app to join the product_owners channels and attend the regular PO meetings. This is a forum for all of the FOLIO POs to be on the same page wrt definition of done, acceptance criteria, and other product development/releases-related topic
  9. Deployment of the LDP App into Kiwi bugfest hasn't been scheduled due to resource constraints, however it can still be included in Kiwi release and can still be tested in other environments (snapshot).
  10. TC's and PC's decisions re: LDP inclusion in Kiwi have not been overruled.

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.

  • Peter Murrayto add a future agenda item for establishing standards for externally-developed apps.
20 min

Juniper upgrade slowness -  https://folio-org.atlassian.net/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:

  • 1. Is the migration process standardized, such as the lowest version, App upgrade, Settings update, data migration？2. Are there migration guidelines, such as estimated times for different scales?

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 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.

Action items

  •