Kristin Martin, Aaron Trehub, Anya Arnold, John Ballestro, Björn Muschall, Gang Zhou, Harry Kaplanian, Ian Walls, Charlotte Whitt, James Fuller, Karen Newbery, Martina Schildt, Martina Tumulla, Michael Arthur, Owen Stephens, Philip E Schreur, Sharon Wiles-Young, Tiewei Liu, Tod Olson, Brooks Travis, Peter Murray, Maura Byrne, Paul Moeller, Christopher Spalding
- Discuss support for modules without dev team
- Begin strategic
Support for modules that do not have a PO/Devs/funding. This came up at the Support SIG regarding a bug in the Courses App - There is currently no dev team for Courses to assign the bug to and there is no clear path for where to address this bug. PC and other councils need to work out how we manage on-going maintenance for apps in FOLIO. This hits on several questions:
(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.
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.
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.
|50 min||Discussions and decision about how PC functions and start to look over this document FOLIO Vision, Strategic Objectives and Initiatives to make sure we now which items belong to PC.||CC put the strategic initiatives into a spreadsheet and identified what they thought was their responsibility. They are now ranking those. CC also identified items that they thought were the responsibility of PC and TC. For next meeting, review the CC document in the context of the strategic objectives document.|