2024-01-18 Tri-Council Meeting

10-11am ET

Attendees: Charlotte Whitt Mike Gorrell , Kristin Martin Jana Freytag Brooks Travis Alexis Manheim Kirstin Kemner-Heek Charlotte Whitt Corrie Hutchinson (Unlicensed) Jennifer Eustis Paul Moeller Amanda Ros Tod Olson Marc Johnson Craig McNally Thomas Trutt Gang Zhou Jenn Colt Ian Walls Martina Schildt Aaron Neslin Jeremy Huff Jesse Koennecke Simeon Warner (from :30)

Regrets: Martina Tumulla

Agenda:

Topic	Who	Description
Announcements	PC/TC/CC Chairs	Any quick announcements that make sense... CC: An Outreach Marketing group is forming - please contact Boaz Nadav Manes if you are interested. PC: reviewing some some functionality for DCB and reminder fee printing. TC: waiting for PC's review for module TCR review; working on some process improvements.
How Many Releases per year do we want?	Mike Gorrell	There was a time when we had four releases per year... then three... and in 2023, even though we planned to have three, we only ended up with two releases. We'd like the three councils to share their thoughts on how many releases per year the project should plan to have. The implications of such a target will need to be assessed, but, the goal of this discussion will be to get a sense for what the issues and preferences are from Tri-Council members' perspectives. Charlotte: from PO perspective, best to plan realistically instead of changing plans midstream Alexis: has the new critical service patch process impacted the release process? It would be good to tie this question into the review of the critical service patch process and the release timing? Do longer or larger releases result in more CSPs because of more functionality? Marc: Not sure how we could really assess this. Martina S.: two per year seems good from user side, but not sure of impact on developer. Jennifer: big releases are disruptive - feel like I am continually testing, leaving two releases a year as a minimum Ingolf for SysOps: opinion that there is no more than two releases per year. SysOps folks will skip releases if more than that. Bottleneck is the testing period. CSP release are not a big deal because they are so much smaller. Ian W.: move to feature-based releases and not rely on timed releases. Time deadlines are artificial. Thomas: like that idea of moving away from timed-releases. Otherwise, two releases per year. More releases per year just makes it more work. Maybe rearchitecture would allow different modules to be released at different times. Craig: two releases per year is the sweet spot. Hosting provider EBSCO appreciated using the time while waiting for Poppy to make some enhancements for Poppy. Ingolf notes this could lead to continuous deployment. We have a ways to go. Jeremy: fewer releases vs more releases can create more pressure for module to enter on a certain release Tod: two releases per year seem like practical approach. There can be frustration when functionality is completed, but has to wait for the release Marc: fewer releases and larger batches leads to self-fulfilling prophesy of bigger/fewer because it results in a higher overhead. Less releases is not necessarily less disruption, just more concentrated disruption, and less incentive to reduce the burden. A lot of effort is the amount of synchronization and amount of retesting that needs to be done. Doing this less frequently gives us less practice. Feature-based released are hard because features may not all be synchronized at the same time. Ian W.: feature-based releases would give us more time to provide better functionality instead of rushing. Kristin: other parts of work, e.g., fiscal calendar and academic calendar, are calendar based and not feature-based, so featured-based releases might come into conflict with this. Kirstin: this problem may be solved over time as FOLIO matures. Pressure should be less as system accomplishes more of what we need. Mike: when we went from 4 to 3 releases was partially due to giving more time to feature development. Agree that FOLIO is changes and it is more mature than it was 2-3 years ago. But they are still pretty big. Mike's summary: pretty significant consensus that 2 releases per year is best target for FOLIO. We are all interested in App Formalization and seeing if we can decouple FOLIO from the monolithic releases and provide more flexibility.
What do we want to get out of WOLFcon in 2024?	Mike Gorrell	WOLFCon 2023 was "late" being announced... but by many accounts it was a very successful conference. September 24th is nine months away, but planning will be starting soon. What does the community want to get out of WOLFcon this year? What guidance can we give the planners (to be identified). Jesse is looking for a point person coordinator for FOLIO engagement with WOLFCon. Weekly meetings, calls to make sure the project is getting what it needs. Two-way communication between the planning group and community to make sure conference planning is working for all. Also looking for a potential co-chair for the conference as a whole. Would work with Jesse on WOLFCon Jenn: Chicago was great–interested in specifically whether people were happy with the governance sessions and whether people are interested in more planning/structure/workshop for council members. Jenn would volunteer to help with this. Kristin: note that we'll have new membership on councils, so it would be good to have a plan in mind. Tod: seemed good to have governance meeting at the trailing should of the conference. Let the conference inform the meeting, but not compete MIke: do people support having the council meetings after the conference? Jeremy: yes. Jeremy: might be useful leading into the conference if we have a specific agenda as well as time for "things as they come up." Setting aside ahead of time lets us prepare. Martina S.: everyone on PC asked to bring one topic in advance and then we discussed and built working groups afterwards, which has helped us accomplish our work Simeon: we talked at Chicago about the possibility of "FOLIO Academy"–a training day for newcomers on FOLIO. If that happens, what should be the balance between nuts-and-bolts using FOLIO and being part of the community Tod: would be good not to take people out of the conference proper Tod: prioritize how we can use synchronous F2F conversations Tod: noted shift away from fewer working meetings to more presentations - is this the right balance? What should be the balance for 2024? Charlotte: more topics relevant for developers. Last two conferences have been more centered around POs/SME needs. A lot of agreement on this - what could be the topics? Kirstin: workshops to exchange experiences and progress that people have made. Day-to-day work and in-depth discussions, move past the marketing Kristin: how can we share our own customizations to make them more available to the community? Jana: getting separate groups of roles to talk in different roles on how to work better together Jesse: question: what should time slots be? Longer breaks/lunch for more unconference? Did people like the 90 minute sessions? Who's going to volunteer? Paul Moeller and Jennifer Eustis volunteer to work with group for FOLIO
How do we make the FOLIO project attractive to new member organizations?	Mike Gorrell	The FOLIO project aspires to have an engaged and dynamic community, including organizations that contribute as members. We have not added many member organizations over the last few years. What can we do to ensure that the FOLIO project is attractive to organizations, to help sustain FOLIO? Jeremy: can we identify groups that have considered FOLIO but chosen something else - could we get feedback on why? Jenn: being a member and going with FOLIO are two different things Ian: ByWater Solutions is not a member of FOLIO SMLLC because we believe that showing up and participating speaks louder and is more effective than a membership model. Tod: data import ais big black eye. People also don't understand point of membership Jennifer: report also lacking Jenn: we need to leave more time for this topic. We need to prioritize our questions, and we spent too long on the first question when we basically agreed Alexis: for smaller libraries, can we help them group together to make it more possible to participate?

Chat transcript:

Jennifer Eustis 9:04 AM
For me as well

Ros, Amanda L to You (Direct Message) 9:04 AM
did you add attendees to the right minutes?

Mike Gorrell to Everyone 9:05 AM
Some problems with my connection

Ros, Amanda L to You (Direct Message) 9:05 AM
never mind :-)

Marc Johnson to Everyone 9:11 AM
AFAIK we have no way to determine if the number of bugs is impacted by the release frequency
It’s worth keeping in mind that the larger the release the more disruptive it is going to be because of how much is in it, which makes it a somewhat self fulfilling prophecy that they require large amounts of effort to implement in an organisation

You to Everyone 9:16 AM
It would be interesting to consider how the application formalization process would impact this.

Charlotte Whitt to Everyone 9:16 AM
For dev teams, then having three releases with three feature freeze (hard stop of all new development), also cause us to have less sprints for feature development

Marc Johnson to Everyone 9:16 AM
Feature based releases are very challenging within FOLIO due to the amount of synchronisation across apps / development teams to line up the features for each release e.g. when one team is ahead of plan and another behind

Mike Gorrell to Everyone 9:17 AM
I agree - we need to understand how the app formalization will impact the size and frequency of releases.

Charlotte Whitt to Everyone 9:18 AM
Not sure, who can answer that question at this point

Tod Olson to Everyone 9:18 AM
I don't think we can answer that until we have some practical experience.

Ingolf Kuss to Everyone 9:20 AM
That is a good Point, Kristin, The question now was about the current release process. If we will have smaller platforms, more releases per year could become possible. In general, the application formalization process could lead to some kind of continuous deployment process in the end (which would be desirable).

Marc Johnson to Everyone 9:21 AM
More releases being higher overhead for development teams is due to architectural constraints and how FOLIO does release not an intrinsic aspect of the frequency of releases

Jenn Colt to Everyone 9:22 AM
Going to two releases should spur the councils to improve the inter council interactions in the review process

Marc Johnson 9:22 AM
How so?

Jenn Colt 9:23 AM
If there is a dependable schedule consider having more dependable guidelines around the timeline for approvals. Have clarity about parallel vs serial processes, etc. Maybe nothing changes but there’s more pressure to get the release you want if there are fewer.

Charlotte Whitt to Everyone 9:25 AM
Less releases does not require more training of staff …

Charlotte Whitt to Everyone 9:26 AM
We have customers who have wanted to skip a release

Alexis Manheim 9:27 AM
I was just wondering if hosting providers do all the updates for every customer...

Kirstin Kemner-Heek 9:27 AM
We have to … or skip.

Alexis Manheim 9:27 AM
For Stanford since we are self hosted, we would not do three a year.

Thomas Trutt 9:28 AM
We get every update from our provider, but they as was mentioned have to set up their internal tooling before it can be released to use, that is at least a few weeks on their end.

Marc Johnson to Everyone 9:29 AM
Ian, how do you solve the synchronisation of which features challenge with feature releases?

Marc Johnson to Everyone 9:32 AM
Bigger features in fewer areas leads to an unevenness for development teams that presents other challenges for how FOLIO plans work
A major constraint for the current releases is the practice of manually regression testing the entire system

That effort will only ever get bigger (unless folks start cutting features)

Charlotte Whitt to Everyone 9:34 AM
The manual testing (Bugfest testing) has been partly replaced by automatic testing

Tod Olson to Everyone 9:28 AM
I think what Marc is talking about is also related to the tight coupling between different areas of FOLIO.

Marc Johnson 9:35 AM
That is certainly part of it

Though that’s highly codependent upon also being organisationally capable of managing independent releases of apps (for want of a better term)

Marc Johnson to Everyone 9:36 AM
If the automated testing is trusted, it should be leader to reduced effort of manual testing for each release

It could be worth trying to measure the ratio between those over time

Thomas Trutt to Everyone 9:26 AM
I also feel that because of the complexity of FOLIO there are really no small features. - another argument for 2 releases a year.

Marc Johnson 9:30 AM
Or an argument for smaller decomposition of features to facilitate more releases

Tod Olson 9:35 AM
Yeah, I'm looking forward to a time when we can look at boundaries and interfaces, which I think will be necessary for such a decomposition.

Marc Johnson 9:37 AM
Technical aspects are part of it.

How we design both the features themselves and the way they are rolled out also needs to change to accomplish this

Jenn Colt to Everyone 9:36 AM
It feels like we are missing some strategic planning steps for FOLIO if we really want to hit these big goals

Marc Johnson 9:39 AM
You know my thoughts on this

I think that most major work should be driven by strategic intentions

Without it, it’s very easy for work to pull in different directions and lack cohesion

Charlotte Whitt to Everyone 9:41 AM
+ 1 Tod re. hands on sessions, workshop sessions

Jenn Colt to Everyone 9:42 AM
The code4lib workshop days is a nice model

Simeon Warner (he/him) to Everyone 9:43 AM
Yes

Craig McNally to Everyone 9:44 AM
I think it worked out well

Charlotte Whitt to Everyone 9:44 AM
Yes, that worked well

Jennifer Eustis to Everyone 9:44 AM
I think it is a good idea. It was hard being hybrid though

Alexis Manheim to Everyone 9:44 AM
Yes, the council meetings after were great.

Paul Moeller to Everyone 9:44 AM
I agree

Brooks Travis to Everyone 9:45 AM
I like the idea of a “workshop/training” day, either pre or post-conference. I think it should be in addition to the in-person council meetings.

Alexis Manheim to Everyone 9:45 AM
Pre work makes sense, Jeremy

Alexis Manheim to Everyone 9:46 AM
I was very happy with what the PC did too, Martina

Martina Schildt | VZG to Everyone 9:47 AM
Agree to Charlotte - 100%

Ingolf Kuss to Everyone 9:47 AM
++Charlotte

Jennifer Eustis to Everyone 9:47 AM
+1 Charlotte

Marc Johnson to Everyone 9:47 AM
What topics are valuable for developers to attend?

Charlotte Whitt 9:48 AM
That’s a question for you Marc 😄

Marc Johnson to Everyone 9:48 AM
How developers and POs / SMEs interact at WOLFCon should reflect the overall cultural norms of the community

Jennifer Eustis to Everyone 9:49 AM
I'd volunteer to be part of the planning group

Kirstin Kemner-Heek to Everyone 9:50 AM
+1 Jesse

Jana Freytag | VZG to Everyone 9:48 AM
I think getting the separate Groups of roles (POs, Conveners, SMEs, Devs, SysOps) to talk in different combinations on how to work even better with each other would make some great Slots for WOLFCon

Marc Johnson 9:50 AM
What is stopping us doing that outside of WOLFCons?

Jennifer Eustis to Everyone 9:51 AM
+1 Jesse. This is also helpful for those who attend hybrid to get up and move a bit

Tod Olson to Everyone 9:47 AM
@Charlotte Whitt , yes, finding ways for developers and SMEs to engage with each other would be quite good.

Marc Johnson 9:51 AM
That effort does not need to be exclusive to WOLFCon especially as many developers don’t attend WOLFCon

Simeon Warner (he/him) to Everyone 9:51 AM
Long lunches, regular breaks

Thomas Trutt 9:52 AM
I started a lot of conversations that cut short by lunch ending.

Marc Johnson to Everyone 9:53 AM
Folks could consider an unconference style for part of it, given folks want to encourage more dynamic topic emergence

Tod Olson to Everyone 9:53 AM
Thinking about volunteering, but need a better sense of my capacity this summer.

Jennifer Eustis 9:53 AM
The more the merrier!

Ian Walls to Everyone 9:40 AM
If we could get to breaking down the monolith, that would be the right solution. feature-based releases are an interim measure until that's possible. I know there are some concerns about the different challenges it presents, but we can already see how poorly the timed releases are working. I think it's far more likely that changing the approach would be an improvement for us than a detriment.

Thomas Trutt 9:42 AM
This was my thought as well.. Ie, Circ’s new feature will that 6-weeks while flow jet’s may only take 3. (Fake numbers)

Ian Walls 9:45 AM
I presume that development teams can reasonably estimate how long features will take. Given all that up front, an initial schedule could agreed on. if one team is done with all their work early, great. once all the new features are ready, then the integration testing can begin

Marc Johnson 9:54 AM
If those estimates were reliable, which they inherently aren’t, then we wouldn’t have slippage of the current release schedules
Even if they were, how do you handle one team delivering a 3 week feature and another a 6 week feature in the same release?

What does the 3 week feature team do with the other 3 weeks?

Jenn Colt to Everyone 9:55 AM
Going with FOLIO isn’t the same as being a member

Charlotte Whitt to Everyone 9:56 AM
E.g. Duke

Jenn Colt to Everyone 9:55 AM
We need to understand the advantage of being a member and not just a customer.

Jennifer Eustis 9:55 AM
What are the benefits versus not being a member?

Marc Johnson 9:56 AM
In part, helping to fund the project, which makes it more likely to stick around as an open source thing

Ian Walls to Everyone 9:57 AM
ByWater Solutions is not a member of FOLIO SMLLC because we believe that showing up and participating speaks louder and is more effective than a membership model.

Jenn Colt to Everyone 9:57 AM
How does the rest of governance access feedback given just to PC?

Jana Freytag | VZG to Everyone 9:58 AM
I have to run to the RA SIG Meeting. Bye all 👋

Jennifer Eustis to Everyone 9:58 AM
+1 Tod. I would add also that there really isn't any reporting in FOLIO

Charlotte Whitt to Everyone 9:59 AM
Sorry, I have to run. Bye

You to Everyone 9:58 AM
Tod, what are your two black eyes? For the notes.

Tod Olson 10:00 AM
First thing isn't a black eye, just a better understanding of how your membership contribution helps the project.
Data Import is the black eye.

Christopher Spalding [EBSCO] (he/him) to Everyone 10:00 AM
Thanks Alexis. EBSCO is still looking at ways to pull the smaller orgs into the community. This came up in the OLF Board meeting this week as well.

Simeon Warner (he/him) 10:01 AM
Glad that you are looking at it Christopher. I think also as a community we have to look at what we offer