2021-09-16 Product Council Meeting Notes

(Charlotte Whitt has stepped in as PO for Courses, but the underlying issues still exist...e.g., Users app)

TC has been asked to come up with criteria for accepting code, and they are working on that.  What criteria does PC have?  Previous iterations of the memorandum of understanding (MOU) required code submissions to be supported for two years.  The upcoming release has 8 new modules being added; SysOps SIG reported that there are over 130+ modules with the new release.  TC is looking at the problem with the growth of modules.  Should money be applied to have contractors fix issues with unsupported modules?  Should libraries that are commissioning development work provide proof of some level of post-release support?

If unsupported modules are supported by people that don't understand the underlying design, how can things like inter-app workflows be supported and improved?

Should we revisit the use of MOUs?  What did the previous MOU say?  There is confusion in terminology: modules versus apps, and where the boundaries exist.  The increasing number of modules is complicating testing because of all of the various possible combinations.  It can take almost three months to complete this testing.  There are modules that libraries use that are not part of the formal release, and that is okay and anticipated in the design.

How the project prioritizes things and allocates resources are intertwined. The ERM apps were funded separately and developed in parallel with other work; it may not have been developed when it was if this hadn't happened.  As a project, we need to find ways to enable new groups of developers to feel welcomed and have their contributions recognized.  Set up the process and documentation for how new contributions are introduced and accepted into the community.

Work on non-functional requirements (NFRs)—the things that the SysOps SIG has been pointing out—are difficult to get funding for; they are difficult to justify to administrations.  The resource allocation process should consider what we can get funding for and what is not.  A newly contributed module should include a more robust testing plan than what comes with Bugfest.  The way we've talked about app stores has served us well in the past, but it highlights the problem of how we make new additions that are not tightly bound to the core.  (Have we missed the opportunity for a robust app store?)  These discussions are at the intersection of all three FOLIO councils.

How do we provide guidance for something that is contributed a part of core as well as enable contributions to work that are not a part of core (a certification system?).  There is a tension between the app store concept and the stability that libraries want/expect in their LSP.

• Hkaplanianto take a request to CC to use funding to support fixes for "orphaned" apps.
  

The project has a shortage of DevOps support—perhaps the project's most severe shortage at the moment.  Solving that problem will help address the other issues.

Can Courses be used as a model for ensuring ongoing support of apps?  A set of criteria from TC and PC plus some perhaps from CC would help ensure that contributed code is supported for some period of time.

• Anya to describe the need for all three councils to defining the criteria for accepting code and where the bar is for getting new development included in the project.  Tod Olson, Hkaplanian, and Kristin Martin to work on arranging this gathering.
  

Topic for upcoming PC meeting: work on PC's criteria for accepting contributed code.  What alternatives exist if a contribution is not accepted; what does it mean if something is not accepted.  The "app store" concept is troublesome because of the intertwined nature of library workflows between apps (unlike a phone's app store).  Minimal from a SysOps perspective is not minimal for what it takes to run a library; a library might look to run ERM without the need for circulation and inventory.  How do we represent these perspectives?

As the Support SIG finds issues with orphaned apps, the SIG can bring those issues to PC to attempt to gather support and resources for fixing.