2024-03-11 Meeting notes

Date

11 Mar 2024

Attendees

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Marc Johnson is next, followed by Ingolf Kuss Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
5-10 min	Liaison Updates	Maccabee Levine Tod Olson Jakub Skoczen Craig McNally Jenn Colt	CC: Maccabee Levine Developer Advocate offer made. CC figuring out hiring logistics Index Data's proposal for doing system administration and CI/CD work was approved, pending budget check PC 6-month review of functional evaluation process. Re-raised request of MOU for module contributors defining their commitment to the module Jeremy Huff asked whether the module evaluation / compliance been considered for the MOU? Maccabee Levine advised that the CC conversation was short and he couldn't recall previous conversations about the topic PC: Tod Olson No PC meeting due to Tri-Council meeting, see 2024-03-07 Tri-Council Meeting notes Planning for a periodic (quarterly?) meeting at an Asia-and-Austrailia-friendly time in order to be more inclusive Jeremy Huff asked if this is a topic the TC should consider? Craig McNally suggested we wait for how the PC experiment goes. Maccabee Levine suggested there could be benefits from more involvement from those folks RSMG Group: Jakub Skoczen Deferred to sub-group updates later Security Team: Craig McNally Tri-council Application Formalization: Jenn Colt
5 min	Upcoming Meetings	All	13 Mar 2024 - Proposal to RSMG for language in the release schedule template suggesting RFCs 18 Mar 2024 - Regular TC meeting 20 Mar 2024 - Dedicated Discussion - Topic TBD 25 Mar 2024 - Regular TC meeting 27 Mar 2024 - Dedicated Discussion - Topic TBD 01 Apr 2024 - Regular TC meeting 03 Apr 2024 - Dedicated Discussion - Topic TBD
10-15 min	Technical Council Sub Groups Updates	All	Quick updates only. If we can't find volunteers for groups, we'll need to add the topic to our backlog and address it during dedicated discussion sessions. Go Programming Language: Jakub Skoczen advised that is in public review Distributed vs. Centralized: Craig McNally advised that is in public review and the subgroup should be closed TCR Process Improvements: Maccabee Levine advised that license evaluation is deferred to the next cycle of improvements Maccabee Levine and Jenn Colt presented the topic of raising awareness of the RFCs, particularly in relation to module evaluations, to the RSMG this morning RSMG raised questions about whether an RFC would be required or not and the timescales for submission and were concerned about additional work Jeremy Huff agreed with Maccabee Levine that there are challenges with conveying the TC's intent with these changes
10 min	RFCs	All	Public Review Application Formalization RFC Go Programming Language for Backend Development RFC Distributed vs Centralized Configuration RFC Craig McNally asked what other channels should these RFCs be announced in? Jeremy Huff suggested that Go should be raised in #development and Tod Olson suggested #sys-ops Maccabee Levine asked what the timing is for the next Application Formalization RFC? Craig McNally advised that further RFCs have been deferred due to capacity constraints within EBSCO
1 min	Decision Log	All	Standing agenda item... is there anything in the decision log requiring attention? ...
30min	TCR Board Review	All, Maccabee Levine and Ingolf Kuss	Owen Stephens remarked that he was expecting the evaluations to be considered next week TCR-40 MOD-Serials Ingolf Kuss presented the evaluation, in particular these topics which are not expected to be resolved by next week: Advised that K-Int has chosen integration instead of unit tests and those should be written in Karate / Cucumber Jeremy Huff asked if the TC are ok with integration tests being used instead of unit tests? whether integration tests need to to provide coverage (if they are used instead of unit tests)? whether the integration tests have to be written in an approved technology? Marc Johnson suggested that there could be a misunderstanding of the language in the evaluation criteria. And that when K-Int folks refer to integration tests, they are referring to as tests that run inside the module build, however span a larger chunk of code than what some folks would refer to as unit tests. And advised that "unit" in the evaluation criteria means that the tests run within the module build Owen Stephens asked what is the aim of the unit test criteria? And suggested the language (of unit vs. integration) can get in the way Jeremy Huff advised that the style of the test is not an issue, if 80% coverage is achieved Tod Olson suggested that the criteria could include the reasoning for why coverage is important, to aid future conversations like this Advised that Sonar does not support Groovy, so Julian Ladisch applied alternative tools and found 3 vulnerabilities and over 3% code duplication Jeremy Huff suggested that the TC could consider changing the criteria from specifically Sonar to more general static code analysis TCR-39 UI Serials management Maccabee Levine presented the evaluation, in particular these topics: There are some incompatible licenses related to shared code that this module uses. This is likely a topic that could be included in the next process improvement review The development team are working on the following: sonar checks (code smells and duplication) test coverage accessibility requirements
Time Permitting	Officially Supported Technologies (OST)	All	Standing agenda item to review/discuss any requested or required changes to officially supported technology lists Check in on progress... does anything else require attention? Next Important Milestone: Review Ramsons (1st party dependencies) and move from ACCEPTED → ACTIVE by 15 Mar 2024 Maybe we should aim to start looking at this on 06 Mar 2024 so we have time for discussion/adjustments Other todo items: Review policies and reasoning on page with intent to vote on approval (Sunflower) Today: On the Quesnelia OST Page: Comment on Groovy2 Marc Johnson Groovy version depends on Grails. This combination is not possible. Grails 6 needs Groovy 3. Switch the OST Page to Groovy 3 or just remove the version. Version removed and replaced with a comment suggested by Tod Olson Comment on Folio-spring-base Version. Changed. Same changes done on Ramsons page.
NA	Zoom Chat		00:03:18 Jenn Colt: I am the othersâ€¦ 00:03:31 Huff, Jeremy T: Reacted to "I am the othersâ€¦" with ðŸ˜ 00:13:40 Jenn Colt: Agree w/Tod. In slack there is evidence of need of this on this on the product side. 00:13:48 Huff, Jeremy T: Reacted to "Agree w/Tod. In slac..." with ðŸ‘ 00:15:38 Owen Stephens: The PoC announced by Craig last week seems very wide ranging and tbh the application formalisation seems like not the most significant part of it? 00:15:56 Craig McNally: That's accurate Owen 00:16:07 Owen Stephens: Reacted to "That's accurate Owen" with ðŸ‘Œ 00:16:13 Jenn Colt: Yeah the tri council conversation is definitely more limited 00:16:19 Owen Stephens: Reacted to "Yeah the tri council..." with ðŸ‘ 00:16:51 Tod Olson: And if we don't have a topic for this Wednesday, we can release the time. 00:23:14 Marc Johnson: We have a hard threshold for the serials management evaluations Please can anything else be deferred 00:26:47 Jenn Colt: The RFC metadata is update, I will merge after this 00:27:13 Owen Stephens: I was expecting this next week 00:27:25 Owen Stephens: I have to admit 00:29:17 Ingolf Kuss: isn't it the 15th officially ? 00:30:00 Marc Johnson: Apologies, I forgot the threshold was after today 00:37:08 Owen Stephens: I have discussed with the development team and I they have suggested some potential tools that could be used for Groovy on Grails applications: Jacoco + codenarc 00:38:51 Owen Stephens: That is as an alternative to SonarQube 00:39:28 Ingolf Kuss: agreed, Marc 00:40:10 Jakub Skoczen: Putting the type of tests and verification tools aside, is the code coverage at 80% or more? 00:40:23 Huff, Jeremy T: Reacted to "Putting the type of ..." with ðŸ‘ 00:40:32 Ingolf Kuss: Julian had used CodeNarc 00:40:36 Huff, Jeremy T: Replying to "Putting the type of ..." That is most likely the more important question 00:40:50 Jakub Skoczen: Imho, this is the core criteria we should check 00:40:59 Tod Olson: Reacted to "Putting the type of ..." with ðŸ‘ 00:41:12 Owen Stephens: Thatâ€™s correct 00:41:37 Ingolf Kuss: Replying to "Putting the type of ..." I don't have a figure about the code coverage. 00:46:15 Marc Johnson: There is nothing qualitative in our criteria about the size of chunk or diagnostic ability 00:50:44 Jakub Skoczen: We can debate the 80% target but imo the benefit of having any target is that the code must be actually run in the CI. Of course higher the better

Topic Backlog
Decision Log Review	All	Review decisions which are in progress. Can any of them be accepted? rejected?
Translation Subgroup	All	Since we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Communicating Breaking Changes	All	Since we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Officially Supported Technologies - Upkeep	All	Previous Notes: A workflow for these pages. When do they transition from one state to another. Do we even need statuses at all ? Stripes architecture group has some questions about the Poppy release. Zak: A handshake between developers, dev ops and the TC. Who makes that decision and how do we pass along that knowledge ? E.g. changes in Nodes and in the UI boxes. How to communicate this ? We have a large number of teams, all have to be aware of it. TC should be alerted that changes are happening. We have a couple of dedicated channels for that. Most dev ops have subscribed to these channels. How can dev ops folk raise issues to the next level of community awareness ? There hasn't been a specific piece of TC to move that along. Craig: There is a fourth group, "Capacity Planning" or "Release Planning". Slack is the de facto communication channel. There are no objections to using Slack. An example is the Java 17 RFC. Craig: The TC gets it on the agenda and we will discuss it. The TC gets the final say. Marc Johnson: We shouldn’t use the DevOps Channel. The dev ops folks have made it clear that it should only be used for support requests made to them. Jakub: Our responsibility is to avoid piling up technical debt. Marc: Some set of people have to actually make the call. Who lowers the chequered flag ? Craig: It needs to ultimately come to the TC at least for awareness. There is a missing piece. Capacity Planning needs to provide input here. Marc: Stakeholders / Capacity Planning could make that decision. Who makes the decision ? Is it the government or is it some parts of the body ? Marc: the developers community, the dev ops community and sys ops are involved. For example the Spring Framework discussion or the Java 17 discussion. But it was completely separate to the TC decision. It is a coordination and communication effort. Marc: Maybe the TC needs to let go that they are the decision makers so that they be a moderating group. Jakub: I agree with Marc. But we are not a system operating group. Dependency management should be in the responsibility of Release management. There are structures in the project for that. Jason Root: I agree with Jakub and with Marc also. Policies should drive operational/release/support aspects of Folio. Jason Root: If the idea of “support” is that frameworks are supported, then of course the project should meet that. Marc Johnson Some group needs to inform OleksAii when a relevant policy event occurs. These documents effectively ARE the manifestation of the policy. Craig: This is a topic for the next Monday session. Craig to see if Oleksii Petrenko could join us to discuss the process for updating the officially supported technologies lists.
Dev Documentation Visibility	All	Possible topic/activity for a Wednesday session: Discuss/brainstorm: Ideas for the type of developer-facing documentation we think would be most helpful for new developers How we might bring existing documentation up to date and ensure it's consistent etc.

Action Items

TC members to review policy guidance in Ramsons OST page and provide feedback