2023-08-30 Meeting notes

Date

30 Aug 2023

Attendees

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Jeremy Huff is next, followed by Marc Johnson
10 min	TCR Board Review	All	TCR-27 - Getting issue details... STATUS Update from Zak Burke : Nothing new to update, will have an update next week. TCR-28 - Getting issue details... STATUS Volunteer needed: Jeremy Huff Volunteered to conduct the evaluation. He agreed to reach out to Radhakrishnan Gopalakrishnan to get things started. Documentation still needs to be updated concerning the evaluation of edge modules in Poppy. Jeremy Huff said that he would put some language together for approval by the TC next Wednesday Relevant dates: 22 Sep 2023 - Deadline for acceptance of new modules by Technical Council at Poppy (R2 2023)
5-10 min	Liaison Updates	Maccabee Levine / Tod Olson / Jakub Skoczen	Updates from CC (Maccabee Levine): The CC had their meeting at the same time as the TC meeting, and it was 4 hours long. Maccabee Levine looked over their notes and did not see anything that needed to be addressed immediately. Updates from PC (Tod Olson ): No adendees for the PC were present. Updates from Release Management Stakeholder Group (Jakub Skoczen ): There was no meeting Updates from the Security Team: No Update
15 min	Technical Council Sub Groups Updates	All	Topics to discuss: Communicating Breaking Changes subgroup needs owner/volunteers WRT our TC shoulder meeting at WolfCon, the formation of a translation subgroup Should we create a subgroup to prepare the TC's initial response to the application formalization concepts? Today: Controlling AWS Hosting Costs: Maccabee Levine this work is 90% done. The only remaining work to be done is a communication piece which is scheduled to be done next month. Maccabee Levine will bring an update at the close of September. Distributed vs. Centralized Configuration: No subgroup members were in attendance. Architecture Review: Jenn Colt Unsure how to proceed given the application formalization discussion and potential groups to explore this topic which were suggested at WolfCon. Jeremy Huff believes that there is both a governance aspect to the architectural changes proposed by VBar and technical aspects. He feels that this subgroup could focus on the technical aspects, and any new subgroup might be scoped to the governmental implications. Maccabee Levine agreed with Jeremy Jenn Colt We need to agree upon the purpose of the Architecture Review group Jeremy Huff Agreed with Jen that the purpose of the group needed to be defined more clearly Owen Stephens We were under some pressure at the Tri-Council meeting to have an actionable response to the proposed architectural changes. It is more important that the work is done in the timeframe which we committed to, than that a particular group of people does the work. We can be flexible about who does the work. This group most likely needs to be broken down into specific areas of focus. Jakub Skoczen agreed that we give this group a more focused goal and that we may possibly need multiple focused groups. Jenn Colt There will be RFC on these topics, and maybe this group can contend with those. Jeremy Huff Agreed with this thought. What if the first deliverable for this subgroup was a recommendation for the specific goals of the group moving forward and other possible groups that may be formed to address the architecture topic? Jenn Colt felt that could work, and suggested contacting Craig McNally for clarity on future RFC. Breaking Changes: No volunteers were forthcoming. Jeremy Huff described the needs of the group, and that the main focus of the next phase was to determine how breaking changes should be communicated in the FOLIO community. Zak Burke volunteered as a group member. Jeremy Huff suggested that we may need to assign people to the task of organizing the group. Zak Burke expressed a willingness to help in producing training and communication of the results of the subgroup, upon its conclusion. Jeremy Huff brought up a question of order: Can the TC create subgroups without a quorum? Maccabee Levinesuggested that the subgroups should be created and that the TC could decide later if they should be removed. Translation Sub Group: Jeremy Huff given the discussions at wolfcon, it seems possible that we may need a translation subgroup. Should we create one? Maccabee Levine suggested that a first step would be to reach out to the vendor who created the recent TCR. Jeremy Huff Suggested that community engagement should be a top priority for the translation subgroup. Owen Stephens the kware folks have shown their interest, but there are many others, and we should cast a wide net in gathering community engagement Zak Burke we have had difficulty in the past getting stakeholders from the wider community on the topic of multilingual approaches. Jeremy Huff Suggested "engagement with the community", "define functional and non-functional requirements", and "shepherd one or more rfc" as goals for the group. Jeremy Huff called for volunteers, Zak Burke volunteered for membership Maccabee Levine suggested that this might be a cross-council group No owner was found. Potential sub-group for non-technical response to the Platform and Application formalization proposal: Jeremy Huff do we need a sub-group for this? Maccabee Levine suggests that the timeframe may recommend not using the subgroup. Jenn Colt had a question about the scope. She is concerned that the questions about implications may encourage a change in governance that may not be required. Jeremy Huff agreed with this concern Maccabee Levine also agreed that the list brought forward by the TC should not be considered recommendations. He also expressed the opinion that some of the possible ways in which the application architecture changes might impact governance may be desired by some people. Jeremy Huff expressed that his goal behind pursuing identifying these implications is to encourage the other councils to have conversations/decisions in place before the changes are made. He feels that something like VBar proposal is likely to take place at some point, but that these changes are going to demand that we make some decisions on governance. He wants the decisions to be preemptive and not reactionary. Jeremy Huff asked Jenn Colt if she would want to participate in the discussion. He has agreed to reach out to the volunteers and organize a meeting time.
< 5 min	Decision Log	All	Nothing new
< 5 min	RFCs	All / Jenn Colt	Link to confluence documentation PR This PR was approved
< 5 min	Officially Supported Technologies	All	Standing agenda item to review/discuss any requested or required changes to officially supported technology lists No Updates
10 min	Decision on Jeremy's Schedule Conflict	All	Options discussed: Swap Monday and Wednesday meeting Long Term Proxy New Co-Chair / Co-Chair Proxy Jenn Colt pointed out that swapping the Monday and Wednesday meetings would allow us to plan the extended meetings on the same week that they occur, and that this could be beneficial.Jeremy Huff agreed. It was decided that swapping the Monday and Wednesday was preferable, and all voting members agreed on this, but we did not have a quorum and it was decided to defer until more TC members could weigh in.
10 min	Review of Tri-Council Meeting	All	Complete Notes: 2023-08-25 Tri-Council Meeting Tom Cramer's excelent summary: At today’s TriCouncil meeting, we laid out a preliminary plan to move forward on the Architectural Evolution for applications. Craig will bundle together presentations and documentation on Application bundling The TC will lay the groundwork and launch an RFC process in the next 1-2 months Craig, Jeremy, Maccabee, Tod will marshal together the non-technical questions, considerations, implications, and scope issues that can be used for structured discussions with the wider community, including PC and CC. This will be done in 6 weeks We will have a Tri-Council meeting on Thursday, October 12 at 9:30 AM ET to discuss the application bundling (Zoom = https://zoom.us/j/867230970) The heart of this work will be in TC for the next couple of months. CC should name 1-2 liaisons who can work with TC and the volunteers named above as needed, so we can be sure there is good communication to and from CC. (PC is considering naming a couple of reps as well.) Are there 1-2 CC members who would volunteer to be coordinators and liaisons for this phase of architectural work? This was reviewed and no new details were added.
?	Continued Discussion on Process Concerns in the wake of Vince's presentations	All	Questions/concerns were raised in #tc-internal about what the next steps are (after WOLFcon) for the topics recently presented by Vince... Getting feedback from other councils Turning these topics into formal RFCs etc. Craig McNallywhat are the next steps for the TC? Craig McNally : the presentation is not viewed as a formal proposal (yet). So far it has been presented to the Council chairs (during the Chicago "summit"). There is an expectation that the presentation will be turned into a formal proposal/RFC. Marc Johnson : not clear what is the TC role until a formal proposal is available. It makes more sense to discuss the next steps. Owen Stephens : the proposal is too abstract to let the PC and people responsible for the product understand what the impact is. For any approvals it is essential to understand what the impact on the product is and what the work entails, etc. Tod Olson : operational and sys-ops related concerts. Jakub Skoczen : can we split the proposal into two parts/phases: 1. Proposal regarding new functionality for managing permissions/capabilities. 2. Architecture/design to support the needed functionality. Part 1. to be reviewed by the parties responsible for product. Tod Olson: sys-ops mentioned permission-management challenges. Concepts similar to "capabilities" are being implemented? back at Chicago. Jenn Colt : the problem is with the scope, the proposal is very high-fidelity and top-down. It would make sense to focus on smaller pieces. VBar the goal was to inject the conversation with some "big ideas" There wasn't much interest in continuing the discussion in a dedicated Monday session. Do we want/need to discuss more? Marc Johnson we should revisit this topic after WOLFCon Ingolf Kuss Discussion in sysops SIG: 2023-08-11 Sys Ops & Management SIG Agenda and Meeting notes Today:
	Zoom Chat		placeholder.
Topic Backlog
Discuss during a Monday 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. Today Notes:

Date

Attendees

Discussion items

Action Items