Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Discuss support for modules without dev team
  • Begin strategic

Discussion items

TimeItemWhoNotes
Announcements
  • Roadmap group anticipates something to share by September 23 meeting.  Themes and sub-themes are identified.  Working to have these represented in Jira.  Talking with POs about how this intersects with other activities (institutional rankings, priority-setting).  There are institutions that aren't represented in the rankings now; how to handle this.
  • PC Roles and Norms group working on document as well
  • CalTech is going live this week!  Best wishes to them in the final stages.
 30 min

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:

  • What apps are considered part of the formal FOLIO community supported suite?
  • How should those apps and the underlying platform be supported long term?
  • Are there any different considerations for apps that are funded or developed externally, then adopted into the core FOLIO?
 Anya Arnold

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

  • Harry Kaplanianto 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 Arnold 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, Harry Kaplanian, 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.

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

Action items

  •