Page Comparison

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. The current document is here.
    • 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.
      • Owen Stephens referred us to Tech Council Charter for guidance on that
    • 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.
  • Marc Johnson suggested this reference for the evaluators: https://sonarcloud.io/organizations/folio-org/projects?search=ldp&sort=-coverage
  • 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.

• 2021-09-02 Product Council Meeting notes from the PC meeting where Tod presented
• 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 needsTechnical needs met when standing up FOLIO installs 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.

James Fuller This feels like a Risk Tolerance situation. If the risk for a module release is very small, I think the folks would be more likely to update more frequently. With the historical risk during an update, currently people are update-adverse.

Marc Johnson The topic of failures in operations that require changes of persistent state in multiple modules has been attempted to be addressed a few times and we haven’t made much progress on doing so (possibly because it changes the nature of the integration patterns).

One of the challenges we have is that the community quite often expresses stances that aren’t compatible with each other e.g. some folks want more smaller modules others want less larger ones.

Ian Walls FOLIO needs to have official 'releases' from a marketing, training and documentation perspective.  but that can also exist with the ability to deploy bug fixes in modules without having to re-roll a completely new release.

Owen Stephens  The discussion at the PC concluded with 3 next steps:


• Can the TC take this on (in collaboration with the SysOps SIG) and refer items to the PC that need to make their way to the roadmap?
• PC needs to have a view of how FOLIO is deployed and used in a library.  Libraries want stability and predictability in the software they are using and the timing of when releases are made.  "What is the FOLIO product...as a suite of apps to manage their day-to-day business."
• All this will require some well-written documentation for, which apps are bundled together, and when a platform feature like Kafka is required.

How useful those are right now, I’m not sure - and I think if the technical council needs guidance from the PC or needs to refer issues back to the PC then that would be very reasonable

• As a PO I need to know what it is that I should be prioritising to make things better for SysOPs. If someone told me that, I’d look at how we could put resources on it.
  This is what we’ve done with other NFRs - specifically testing.

The SysOps SIG has suggested and advocated for NFR work in the past, but it always gets ranked at the bottom and never prioritized. SysOps also has no PO.