2024-04-01 Meeting notes

Date

01 Apr 2024

Attendees

Jeremy Huff

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Jakub Skoczen is next, followed by Taras Spashchenko 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 PC: Tod Olson - No PC meeting last week RMS Group: Jakub Skoczen Security Team: Craig McNally Tri-council Application Formalization: Jenn Colt Applications questions completed, working on summarizing and determining action items
5 min	Upcoming Meetings	All	03 Apr 2024 - Dedicated Discussion - ??? 08 Apr 2024 - Regular TC meeting 10 Apr 2024 - Dedicated Discussion - Topic TBD 15 Apr 2024 - Regular TC meeting 17 Apr 2024 - Dedicated Discussion - Topic TBD 22 Apr 2024 - Regular TC meeting 24 Apr 2024 - Dedicated Discussion - Tentative POC Q&A. POC Info: https://docs.google.com/spreadsheets/d/1zzW2I1xMhdUpkclQRE2NvCcvx6JlNYUG4aTOiaYraJ4/edit#gid=1733306425
4 min	TCR Board Review	All	TCR-38: Florian Gleixner
5-10 min	Technical Council Sub Groups Updates	All	TCR process: still working with RMS, then some communication that may or may not wait for RMS Existing modules: some criteria should apply, but current review process doesn't Return to process after formalization Working on static code review subgroup, need to reach out to devs
5 min	RFCs	All	Public review update Application Formalization RFC - some comments, need to dig in Not a ton of feedback, need to incorporate changes and then move along Go Programming Language for Backend Development RFC - active comments Distributed vs Centralized Configuration RFC - is in public Review
1 min	Decision Log	All	Standing agenda item... is there anything in the decision log requiring attention?
5-10 min	Open Call to Devs for TC Backlog Topics	Jeremy Huff	Review the following language: Hello FOLIO Developers! The FOLIO Technical Council wants to ensure that we are engaging with topics that are relevant to the development efforts of our community. We feel that no group is more aware of what these topics are then the developers themselves. We would like to encourage you to share with us suggestions for topics that that are impactful to the FOLIO development experience. Please share any such topic suggestion with us in the #tech-council slack channel, and thank you for all the hard work! ___ Jeremy will post for developers + slack channels
10-15 min	FOLIO Breaking Changes Utility PoC	Maccabee Levine	Mine GH for evidence of breaking changes, ask teams to add labels to PRs see 2024-02-21 - Communicating Breaking Changes https://docs.google.com/spreadsheets/d/1jHfxvNQRnQuHeCcv0NlSc6eti0IHEyVTe4eO1q419gk/edit#gid=0 https://github.com/folio-org/breaking-changes-notification-poc Once things are gathered what happens? Posts to slack channel where interested parties can watch for changes and see if they are affected. Hoping summary in PR will let people know if they need to investigate further. Have release notes with breaking changes but those are too late. Try running the POC for a while and see how it goes. Need to make sure development community understands how to do the labels. Description is optional but useful. See if some set of teams thinks it is worthwhile and willing to try. Olamide: Things could get missed in the slack channel, knowing before the change is merged is most helpful. Any major version change should be accompanied with the label. A way to force agreement? Would we want to? How do teams currently signal? Nothing formal. This is an attempt to provide the mechanism. Tech leads could be an option but that group didn't work so well. Is there a better way than slack to make people aware of breaking changes. Hard for TC to facilitate announcement before it is evidenced in code. PR is the earliest can automatically scan for, anything else would require active participation from the dev teams to make announcements. Some kind of notification when the PR is created, if PR has the label, could make it happen earlier. Targeted to teams working on specific modules? Slack notifications can be used to let people to opt into their own announcements. Individuals can set up their own notifications People not attending them to later in the process, or not realizing they were breaking changes, leading to some scrambling Try with limited scope experience Use a Wednesday topic discussion and try to get folks already using the breaking change label to try this Can also give refresher link on definition of breaking changes At one point teams were responsible for creating PRs when they made breaking changes that affected other modules Make sure useful for development teams and sysops as well Jeremy will publicize upcoming discussion
5 min	WOLFCon Presentation Updates	Jeremy Huff	Proposal: give feedback, have until end of the month
Time Permitting	Officially Supported Technologies (OST)	All	Standing agenda item to review/discuss any requested or required changes to officially supported technology lists
Time Permitting	Topic Backlog Grooming	All	Review the topics on our Topic Backlog to remove those that are no longer relevant, modify those that require change, and add topics that might be missing.
NA	Zoom Chat		11:02:09 From Jenn Colt to Everyone: Same here 11:06:35 From Jenn Colt to Everyone: Overly proactive 11:12:05 From Tod Olson to Everyone: I need to step away for a couple minutes... 11:18:52 From Tod Olson to Everyone: ...back 11:23:48 From Jenn Colt to Everyone: I’m also nodding with my camera off which definitely helps 11:23:58 From Tod Olson to Everyone: Reacted to "I’m also nodding wit..." with 😆 11:24:15 From Maccabee Levine to Everyone: Reacted to "I’m also nodding wit..." with 😆 11:40:53 From Maccabee Levine to Everyone: And even if the dev teams signaled each other about breaking changes, it would not help signal external apps that use the APIs 11:58:23 From Jenn Colt to Everyone: Implementers might just give async feedback

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