30 min | Scope/Criteria Group Update | @Kristin Martin | Slides Functional Criteria Memorandum of Understanding Presentation of slides by @Kristin Martin : ongoing struggle with some definitions: "app" is a collection of functionality potentially spread across multiple modules goal: solve some pressing concerns; lay groundwork for dealing with some present and future challenges. "orphaned" apps continue to be an issue ("orphaned" vs "under-resourced") introduce new functional criteria, diff proposals against roadmap, diff proposals against existing impls. discussion of the PC's role in deciding whether a feature (and thus an app impl'ing that feature) should be included "in FOLIO"; these criteria are still being presented to councils for discussion, acceptance MOU states expected baseline functionality (i18n, a11y, licensing, development support, etc); note this is NOT a contract, but should help est. expectations among a team proposing an app. Want to avoid barriers, but do need to establish rules and expectations Future: marketplace of modules: core, approved, recommended/compatible; is there some kind of "works with FOLIO" rubber stamp? "Approved" things are vetted and under the FOLIO umbrella; "Recommended" could be third-party, different license etc. Hoping for review (and hopefully acceptance) by mid-June for current flower-release-based process
@Jeremy Huff : so much to discuss here! Can we put the action items on next week's agenda? core/approved/recommended: reality is that we make a resource commitment to a module so it seems like some kind of gatekeeper process is necessary to make sure we can be responsible stewards. @Zak_Burke : barriers to contributing are not necessarily bad! we should say "no" as much as possible to new feature commitments so we can really be conscientious about resource committments @Maccabee Levine : MOU: assessment at the end of the two year needs to look at both support of existing functionality, but also continued development as desired features evolve. Need to set expectations about the assessment will be, so a team can know what it needs to do to maintain an app in a given circle, without it migrating out. @Jeremy Huff : maybe the TC will need to evaluate things on an ongoing basis? @Tod Olson : there are very clearly somethings that are outside of FOLIO (e.g. VuFind) but it would be really nice to be able to say, "X is FOLIO-compatible". Easy to imagine apps that could be in an inner-circle, but not wanting to hand it over and lose control of it. Need approval on both sides of the community. @VBar : there are practical and conceptual concerns here. Once a team has contributed something, they will have signed over the rights as well, then it's OLF's choice about whether to accept a given modifications. There's a distinction to be made between OOS licensing models and the IP rights. Move "flower releases" into FOLIO core, reducing their scope, i.e. have lots of things that are "needed" as part of FOLIO but are not always part of FOLIO-core. Example: note a "VuFind connector" could be part of FOLIO-optional but of course VuFind itself is never part of FOLIO. @Kristin Martin technically, OSS is OSS, anybody can build whatever they want if it's not part of an "official" distribution. @Jeremy Huff : gotta talk about how changes like this would affect TC's evals, require new eval.
|
10-15 minutes | Tool/Dependency Versions | All | ** DID NOT ADDRESS; ran out of time ** Notes from last week: The question was raised in slack by @Marc Johnson How do we make tool version decisions? I’m asking because FOLIO is currently on Java 11. I imagine it could be prudent to move to 17 (the next LTS) at some point.And it seems that the #stripes-architecture group made the decision to move the project from Node 14 to 16 recently.I don’t think there is an equivalent group for the back end. How do we envisage the project making these kinds of decisions?
Some feedback was given, but it's probably worth discussing as a group. Should we form a sub-group to define policies/processes? Today: there was some discussion and some comments; in general, the problem is relevant for the backend, frontend, and infrastructure. Agreed to make a placeholder for next week, and once again contact in search of volunteers Today: |