2021-09-08 Meeting notes

Philip Robinson is scribe, followed by Jakub Skoczen 

• WOLFCon planning
  • Philip Robinson suggested dedicating part of a future TC meeting on WOLFCon planning. General questions for now are, how many sessions do we want to do? How long should they be? And of course topics. The TC will discuss when we have more bandwidth for it.

Ian Walls

Zak Burke

• Update on this effort for this effort? (Ian Walls)
  • Need to approve the acceptance criteria, or define an approval process.
    • There are still outstanding questions in the document. How resolve them?
    • Decide on lazy consensus approach or formal voting - assuming we resolve the outstanding issues. Decision to go with voting.
    • Reviewed the acceptance values and criteria. Discussion of "chicken-and-egg" situations like needing to have the source code in folio-org GitHub, so that means it's already approved? Added language to clarify that the expectation is that the code would go there once accepted.
• Communication back to PC? (Zak Burke)
  • How was the presentation of TC external contribution eval plan received by the PC?
• Next steps? LDP validation is due 9/24.
  • Who will perform the LDP app evaluation? d 
    • Front end: Zak Burke
    • Back end: Jeremy Huff
  • How much time is needed to perform the evaluation and formulate a response?
    • Shoot for within a week, by Wednesday 9/15 for the TC to discuss the findings.
  • When can the evaluation start?  (Assuming the TC approves the AC today)
    • Immediately if the TC approves the AC
  • What are the expected deliverables/artifacts out of the evaluation? 
    • Reviewers should come back to the TC first - but this compresses their deadline in order to give any feedback to the LDP team.
    • Once the TC is all on the same page with the review, communicate it - decide on exact recipients next week.
  • Where will the artifacts generated by evaluation be captured?  (wiki?  email?  google doc? etc.)
  • Subgroup to continue refining the AC and defining processes in parallel to the evaluation?

Tod Olson

SysOps SIG representative(s)

SysOps would like some time on an upcoming agenda. The SIG has been working on a list of Operational and SysOps needs and are looking for help on how to advance these needs. The concerns also overlap somewhat with the values/criteria for accepting external code, so it seems like good timing.

• The SysOps SIG would like to address the difficulty getting technical and operational needs met when standing up FOLIO installs. The SIG is reaching out to the TC and the PC to raise these issues and try to get traction on resolving them.
• Ingolf Kuss : There's operational technical debt with all the tight-coupled dependencies among modules. With 3 releases per year, going down to 2 at some point, it's getting more inefficient. It's moving away from an agile microservices approach and seems monolithic. We need to define module boundaries. A smaller core is desirable, not with 50 modules. More optionality in what needs to be installed - like an app store.
• jroot : has a lot of hands-on experiencing installing FOLIO on various versions. Reference to the Operational and SysOps needs wiki doc listing the challenges and needs. The SysOps SIG presented to the PC last week about these issues. There's a lot of technical debt in the way FOLIO has focused more on new features than core functionality. One example of a pain point is sometimes having to back-port modules so a feature works in new releases.
  • The major concern is that this will all get worse as new tech platforms are incorporated into FOLIO.
• Zak Burke discussed the longstanding delicate balance between stable Flower release deployments and the ongoing need to satisfy the community's new feature requests. Sometimes there's frustration among module developers about having to wait for a major release rather than just patching their module to fix or improve something.
• Jeremy Huff : Could the number of modules be reduced at some point to address the issue? Are optional "soft" dependencies possible, to reduce the problems in inter-module functionality?
• Tod Olson : If there are errors, how should they report/flow backwards if there's a problem at an end point module?

Likely to require additional discussion as well as a subgroup and/or time slots in coming weeks. How should we move this forward?

Brandon Tharp the TC should decide how to lean on the FOLIO community to resolve the issues, and advocate for architecture change.

Jeremy Huff One restriction is that the TC does not allocate developer time. The most we can do is advocate and lobby for a strategy that the TC would promote. Define goals of how FOLIO should be, where things currently fall short, how to head off future technical debt as well as remove the current debt.

Zak Burke A challenge is that we don't have an "NFR" SIG or library to advocate for non-functional requests. FOLIO is more motivated by SIGs and Libraries who are mostly feature-driven.