2022-06-01 Meeting notes

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Dennis Benndorf  is next, followed by Zak Burke 

5 min

Review outstanding action itemsAll

No explicit updates

1 minTCR Board Review

All

TCR-9 Volunteer/Assignee: no movement at this time, and not expecting an assignee until the i18n sub-group forms and meets
5 min

Technical Council Sub Groups Updates

All


Notes from last week:

  • Tech Eval Process Subgr
    • today is the target end-date; wrap-up is near. Marc Johnson : folks have had plenty of time to provide feedback at this point and they haven't; general feeling that we'd be best served by finishing now. 
  • What is the RFC process? Radhakrishnan Gopalakrishnan : what does the "public review" phase specifically entail?
      • announce on new public slack channel
      • open for review for 4 weeks
      • expect comments on the PR
      • expect the RFC sponsor/submitter to resolve all discussions
      • note: scope changes are not permitted at this point, maybe (but hopefully not) allowing rare exceptions
    • plan is to try this out, but ack it's not set in stone and may evolve. it's ~3 mos end to end at this point, but want to compress it as much as possible to keep teams engaged.
  • Tech Council Goals: Tod Olson : Sys-ops is prepping its own document of "pain points" that better describes how they manifest; specific discussion around Okapi is planned (there are two diverging visions about if it should do more, do less) but unclear if it will make it into the pain-points deliverable; unlikely to finish by 2022-06-08. Likely/hopefully a WOLFCon topic too.
  • i18n: Zak Burke
  • AWS: Peter Murray : nothing to report at this time.
  • Tech doc/onboarding: Radhakrishnan Gopalakrishnan : no updates at this time; planning to contact Masha but haven't yet. 


Today:

10 minLocalization RFC
30 minScope/Criteria Group Update
  • 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.
      • Will add this to next week's TC agenda
10-15 minutesTool/Dependency VersionsAll

** 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:


Action Items