2023-10-12 Tri-Council Meeting
10-11am ET
Attendees: Kristin Martin Alexis Manheim Owen Stephens Jeremy Huff Tod Olson Jesse Koennecke Florian Gleixner Maccabee Levine Peter Murray Mike Gorrell Brooks Travis Martina Schildt Jenn Colt Paul Moeller Gang Zhou Lisa McColl Maike Osters Ingolf Kuss Martina Tumulla Ian Walls Marc Johnson Adel Brandon S. Lambdin Jennifer Eustis
Regrets:
Charlotte Whitt Simeon Warner Jennifer Eustis
Agenda:
Topic | Who | Description |
---|---|---|
Announcements | ||
Platform and Application Formalization | Re-Architecting Impact on the Product Council document discussion Jesse: Formed subgroup to look at re-architecting proposal impact on PC
Owen: What does endorsement by PC at this point mean? Maccabee: The bullet points (under Should PC endorse this vision? section) should be the next stage. Jesse agreed and will update wording in the doc. Marc: RFC process is proceeding, as agreed at the WOLFCOn tri-council meeting Jesse: Some of this may surface during RFC and stakeholder engagement Mike: Don’t see a definition of the vision. Is there a document that encapsulates it? Owen: vision as presented at WOLFCon 23 sessions and at PC presented in Septs Kristin: Started out as a thought experiment. How do we make sure what this is actionable? Marc: Craig and Vince are working on a draft, may not have formally entered RFC process yet Jesse: RFC process can run parallel to council work Jenn: Process we are defining depends on what the purpose of the process is. Doc outlines the problem which is the unsustainable flower release process. If the process we are defining is starting to tackle that problem, form structures to work on that even before the RFC process is all the way through. RFC is only one answer to the question but it’s not going to be the only answer. Under review is just a description of the JSON file that says what an application is. A whole lot of other decisions are needed. Disconnect on how quickly the councils can move, vs. how quickly dev teams are doing things. If councils move faster, that might be ok. Think through problems before they manifest from teams. Jeremy: Echo what Jenn said. TC tries to scope decisions around purely technical issues. Isolation of tech issues is not always perfect. Appropriate to scope RFCs narrowly but will their approval be interpreted as permission to move ahead with the whole endeavor? Those two things are not the same. Owen: Hoped that this doc was the PC trying to get started, and if it isn’t, what can it do to better to address questions? Maccabee: Doc does a good job of raising questions, as does the TC doc (FOLIO Platform and Application Formalization Questions.) The process of getting PC approval before TC review doesn’t stop us from asking/answering these questions. Also, how do we know when we are done? Tod: We are technically locked into flower releases and need something like app formalization to ever have a chance to do something different. Right now, we are at an early enough point that even if long term vision is not fully known, we do know we are unhappy with flower releases, need flexibility, and this seems like a way forward. Having the technical parts of applications move forward at the same time the PC and Community figure out how to deal with it is ok. We should not wait. This is an opportunity. Alexis: Surface the risks as well. Not a reason not to move ahead, but they need to be discussed. Kristin: Need to work in harmony with whoever is working on this. Move from thought experiment, to proposal, to thinking about implications. We have a lot of live libraries, can this be tested out first? Who would put this into place, and how can we engage with them? Jenn: Include risks in a project plan. Do some project management. Isn’t technology alone. Create an optimistic vision of solving the flower release issue in a project that includes the technical work. Jeremy: Managing this like a project is how it should happen. We don’t have a process in place and this is unchartered territory. We are the ones to develop and implement this process. We have consensus that this needs to happen and should put together tri-council subgroup, 1 or 2 members per council to outline what the process should be, vote on it, and begin work.
App formalization will be a big deal and will enable us to take a platform approach to distributing FOLIO. Is it worth doing even if we don’t formalize the platforms? Important ideas to wrestle with. Maccabee: Agree we need to ask questions to mitigate risks. Ex: Dev team manages app instead of modules, implications for community dev. Approve by each council, app or module? Tod: View from SysOps is that being able to deal with deployment at that app level rather than module level would be a win. At debugging level, ops staff need to figure out where to look for problems, even having an operational actional mapping gives a better sense of where to look. Bridge between functional level and technical levels. Practical benefits. Jeremy: There are reasons to do app formalization regardless of whether we define platforms. Marc: Want to get into the details of how this will improve things, understand what challenges we want to solve, and how these proposals solve them. Put in place a process for how we get there. What happens next? Kristin: Heard a few suggestions of what should happen next. Cross council group, project plan. Who is going to do the actual dev work? Who do we ask? Jenn: Don’t think we can ask Vince and Craig to map this out. They are going to solve tech problems, but all the things that are happening in the community are not their responsibility. Jesse: Merge these approaches? Get tri council group to work with VInce and Craig? Kristin: Yes, circle back to Vince and Craig. Owen: Accept that it needs to be a collaboration, but still thinks the PC should endorse the vision. What role do we have when work is being done by teams not under our direction? Kristin: Council chairs meet regularly and can talk about the tri-council group. |
Notes from chat:
Owen Stephens to Everyone 7:12 AM
This report hasn’t been separately presented to the PC so the PC hasn’t had a chance to consider whether it endorses the vision based on this recommendation. What form that endorsement takes or what endorsement means is also a reasonable question
Jesse Koennecke (he/him) to Everyone 7:12 AM
https://docs.google.com/document/d/1yxF-D47tpTmiusJYn8XtWbFKnk2ZapSvxH2kxEmE-F8/edit
Maccabee Levine to Everyone 7:17 AM
The RFC will (likely) *not* surface most of these questions -- it's designed for technical / architectural considerations.
Jenn Colt to Everyone 7:17 AM
The initial RFC is very narrowly scoped
Marc Johnson to Everyone 7:14 AM
The RFC process is already proceeding
Maccabee Levine 7:15 AM
Agreed and apologies if I implied otherwise. I guess I'm saying these "provided" steps should proceed alongside, and be completed before the RFC is completed.
Marc Johnson 7:17 AM
I only wanted folks to understand that we’ve already started parts of the process (that could do with further definition)
Jesse Koennecke (he/him) to Everyone 7:22 AM
The Indigo Girls are playing in Ithaca next week.
Marc Johnson to Everyone 7:22 AM
Do we know if teams are doing work on this already?
Marc Johnson to Everyone 7:25 AM
Folks mentioned that the decision to progress this might not be the councils. If it isn’t the councils, who makes that decision?
Mike Gorrell to Everyone 7:30 AM
brb
Marc Johnson to Everyone 7:31 AM
The flower releases aren’t a solely technical process
Much of what happens in the flower releases is not constrained by technology decisions
Marc Johnson to Everyone 7:32 AM
We should be aware of the potential challenges of getting too far ahead with the technical aspects where product decisions would lead to rework
Mike Gorrell to Everyone 7:32 AM
b
Martina Schildt | VZG to Everyone 7:33 AM
+1 to Alexis
Maccabee Levine to Everyone 7:33 AM
Alexis++. If we talk through the risks, assuming they are worth it, we can figure out how to mitigate them.
Marc Johnson to Everyone 7:35 AM
The scale of this decision goes beyond most of the technical changes development teams have made in the past (the most similar is probably the changes to Kafka)
Marc Johnson to Everyone 7:33 AM
What challenges with the flower releases do we believe are resolved by this work?
Owen Stephens 7:33 AM
I think We’ve tried to outline some of that (as far as we understand it) in this document
But the document has quite a lot of questions at this stage
Marc Johnson 7:36 AM
I was mostly dropping the question to trigger thoughts
I haven’t read the PC document in detail
Marc Johnson to Everyone 7:37 AM
I agree with Jenn that is could be valuable to frame it around what we want to achieve (the challenges with the flower release) rather than the how (apps and platforms)
Owen Stephens to Everyone 7:37 AM
The challenge of this being project was discussed in tri-council in Chicago. I thought that was the whole point of us doing this work was to get to a point where the shape of what happens next is clearer
Marc Johnson 7:37 AM
I would very much like us to talk about what happens next
Marc Johnson to Everyone 7:38 AM
Jeremy, what process would that group move forward?
Jenn Colt to Everyone 7:38 AM
Jeremy is!
Owen Stephens to Everyone 7:37 AM
The RFC was part of this process as I understood it - proposed by TC members at the tri-council meeting
Marc Johnson 7:39 AM
Yes, that was agreed at the last Tri-Council meeting
Marc Johnson to Everyone 7:42 AM
It’s worth remembering that FOLIO already has a thing called a platform that defines a composition of things to form a FOLIO system
Brooks Travis to Everyone 7:52 AM
I think we need a broader formal proposal
Marc Johnson to Everyone 7:52 AM
Are we ready to create a project plan?
I imagine the folks we should ask whether this is already being developed should be Vince and Craig as they have been representing this proposal from EBSCO
Marc Johnson to Everyone 7:48 AM
They will still be dealing with modules for many operational aspects
For example:
* Logs would still be at the module level
* Parts of the system like okapi are unaware of applications in the proposal
Ingolf Kuss 7:55 AM
The Application Manager could become a part of Okapi.
Marc Johnson to Everyone 7:55 AM
Given we are talking about delivering this, are we agreed that it’s going to happen?
Huff, Jeremy T 7:56 AM
I do not think so
Maccabee Levine to Everyone 7:56 AM
Agree with Jen. The proposal writers have specifically & honestly acknowledged that there *could* be community implications, but deciding how to address those was up to the community.
Marc Johnson 7:57 AM
There are definitely community impacts
Owen Stephens to Everyone 7:57 AM
Maybe “all” is overdoing it on my part but I think any work has to engage with those who are motivated to actually do work
Marc Johnson 7:58 AM
Agreed, this has to be collaborative and needs to work for all parties
Jenn Colt 7:58 AM
Agree. I just think work is more than the code especially since it seems like at least some of this is process problems
Jenn Colt to Everyone 7:59 AM
I think the councils need a project manager for their part or we aren’t going to get anywhere. I’m not saying we should micromanage dev teams
Maybe PM has too much weight. Who is scheduling meetings? Who is working on process? etc
Tod Olson to Everyone 7:43 AM
Also, the flower releases are not the only driver for the Application Formalization specifically. Simplifying deployment is another, related, driver. There's broad consensus in SysOps that being able to deal with deployments at the application level rather than the module level would be a practical benefit for operations.
This is not a unanimous view, but does have broad consensus.
Marc Johnson 7:44 AM
A crucial aspect of that is that applications are composed of modules
And applications themselves are not deployed
Which leads me to wonder how applications solve that deployment challenge?
Ingolf Kuss 7:58 AM
Dependencies will become more clearly visible when modules are encapsulated into applications and the number of dependencies will be reduced in the course of the work.
Marc Johnson 7:59 AM
How will the dependencies be more visible?
The dependencies will exist at both levels, making it potentially more complicated to work out
Ingolf Kuss 8:00 AM
It is then obvious that modules inside an application are dependent on each other, and cross-application modules will be indepenent (hopefully).
the number of dependencies will reduce if we look at the application Level.
Marc Johnson 8:02 AM
That’s unlikely. For example, the users UI relies on circulation
Ingolf Kuss 8:02 AM
yes, true
Marc Johnson 8:02 AM
Unless they are in the same app, there will be dependencies that cross apps
And might be hidden
Owen Stephens 8:02 AM
Thanks all