2023-09-06 Meeting notes

Jenn Colt had an article published in the Code 4 lib journal

Marc Johnson is next, followed by Ingolf Kuss 

All

TCR-27 - Getting issue details... STATUS

TCR-28 - Getting issue details... STATUS

• Zak Burke stated that the outstanding issues (one related to WCAG accessibility and one related to layouts) for TCR-27 have been resolved, and that the module now passes evaluation

• 
  

  Maccabee Levine Asked what the resolution was to the choice between linking to the wiki or the official documentation? Zak Burke advised that they chose to link to the official documentation and the link no longer leaves FOLIO, which was considered disruptive to the user's workflow

• Jeremy Huff  advised that he has started TCR-28 and has scheduled a meeting with Radhakrishnan Gopalakrishnan this coming Friday

• TCR-29 - mod-fqm-manager
• TCR-30 - edge-fqm
• TCR-31 - mod-lists - Tod Olson volunteered to evaluate, supported by Craig McNally 
• TCR-32 - ui-lists - Zak Burke and Maccabee Levine  volunteered to evaluate

• Craig McNally asked if the PC were already aware of the lists app? Matt Weaver confirmed this to be the case. Owen Stephens advised that the PC has had a demo of the lists apps, however they have not had a discussion about it going forward for evaluation
• Craig McNally Will contact the PC to advise them that these modules have been submitted to the TC
• Craig McNally asked for volunteers to conduct evaluations? Jeremy Huff suggested one evaluator could do both mod-fqm-manager and edge-fqm together, and asked whether mod-fqm-manager or mod-lists was smaller? Matt Weaver advised that they were similar sizes
• Marc Johnson advised that if these modules are intended to be included in Poppy, evaluations will need to be completed within 2 weeks rather than 3 due to the Poppy threshold being on the 22nd September
• Maccabee Levine asked if we are blocked from completing our review process before PC does their review? Craig McNally advised that whilst the documentation describes them as happening in sequence, partly to reduce the chances of TC evaluating modules unnecessarily, in practice they have worked in parallel. And suggested that, given that how close we are to the Poppy threshold, the TC should at least start these evaluations
• Zak Burke volunteered to take on TCR-32
• Jeremy Huff is reluctant to take on another evaluation due to currently working on TCR-28
• Tod Olson volunteers to help out with, rather than own, one of the evaluations
• Jeremy Huff offered to ask TAMU for a developer to conduct one of these evaluations. Craig McNally asked what the turnaround time if for that? Jeremy Huff suggested he could have an answer by the end of the week
• Matt Weaver advised that mod-lists should be a fairly straightforward evaluation, whereas mod-fqm-manager requires more nuance because they are expecting this to not pass the evaluation
• Marc Johnson Asked if we want to talk about the reasons why folks are expecting this evaluation to fail? And advised that given the timescales for Poppy, and the political will to do so, maybe we need to get started on discussing that reason for failure otherwise we will likely run out of time
• Craig McNally Asked how that might work? Marc Johnson suggested he did not know and that evaluation could go ahead at the same time. And advised that in the past, we've advised that if a self evaluation fails, then we should not continue with the TC's evaluation. However, this case seems different and we start with a brief conversation either now or the soonest TC meeting available to understand why folks are expecting this evaluation to fail and what is concerning folks
• Maccabee Levine suggested that we should do as much as we can in parallel, however any approval should be serialized
• Craig McNally volunteered to take on TCR-31 and asked Jeremy Huff to contact TAMU to request a developer to evaluate mod-fqm-manager and edge-fqm
• Craig McNally suggested we discuss the concerns folks have with mod-fqm-manager on Monday with Matt Weaver in attendance to provide the context. Jeremy Huff concurred with this idea
• Jenn Colt suggested a summary be written before Monday's meeting for folks to prepare. Marc Johnson stated that he quickly read through the self evaluation and understands why folks are concerned. He suggested that the module breaks a fundamental architectural decision within FOLIO that is expressed in the criteria. And thanked the development team, and Matt Weaver , for their honesty in disclosing this
• Zak Burke advised that ui-lists is written in typescript and asked if anyone has worked with typescript? Jeremy Huff advised that he has and offered to support Zak Burke in that evaluation
• Craig McNally asked what the other potentially controversial aspect was? Matt Weaver advised that edge-fqm does not meet the coverage metric due to the small amount of overall code in the module and did not want to add tests solely to achieve coverage. Craig McNally recognised that this isn't the first example of this
• Craig McNally to set up Monday meeting to discuss concerns around the evaluation of mod-fqm-manager
• Marc Johnson Asked Craig McNally if he has a conflict of interest in evaluating a module produced by the same organisation? Zak Burke advised that he has the same potential conflict. Craig McNally asked if other folks were concerned about this potential conflict of interest? Jeremy Huff stated that he trusts them conduct the evaluations objectively and that our process has a safeguard if the TC is concerned about the validity of the evaluation. Tod Olson advised that the bigger conflict of interest would be if a member of the same team conducted the evaluation and that the same organisation is a much lesser concern. Jakub Skoczen agreed
• Craig McNally suggested that Tod Olson collaborate on his evaluation of mod-lists
• Jakub Skoczen asked why we are still conducting the evaluation when we know it is going to not meet the criteria? And suggested the only other option we have available to us is to change the criteria. Craig McNally suggested that this can be an iterative process and can be used to seek the TC's guidance on a subject. Jakub Skoczen suggested it will take more than 2 weeks to potentially change that criteria. Matt Weaver stated that the team hoped that an exception could be made for this situation.
• Marc Johnson stated that means Monday's conversation is about granting an exception rather than changing criteria. And expressed that this process could have been potentially easier had the team raised awareness of this design choice prior to the module being submitted for evaluation (intending to echo a comment Jenn Colt made in the chat)
• Jeremy Huff suggested that the design conversation would've been better had in the context of an architectural RFC, however he agreed with  VBar statement in the chat that failure isn't a forgone conclusion and that whilst the whilst the principle under consideration is a good one, we should consider any potential mitigating factors
• Jakub Skoczen asked what making an exception in this case would mean because we had agreed in the past that exception would not be made to the criteria. Especially that in this case we are discussing deliberate design decisions that are unlikely to change, unlike a shortfall in code coverage, which could be resolved in the future, and in practice would be changing the criteria
• Craig McNally stated that we would make our best efforts to conduct the evaluations and discussions in time for Poppy. And advised that were mod-fqm-manager to not be accepted then none of the modules could be accepted because they are dependent upon it
• Jenn Colt shared that the lists apps has been demonstrated to the community for an extended period of time, including to the PC and at WOLFCon, and thus these design decisions should not have been a surprise to the TC, given there should have been time to present the technical aspects to the TC prior to the evaluation. And suggested that in the future, funky decisions like this could be raised earlier to avoid the surprise because it was known. And raised concerns that the way this was raised doesn't feel in super good faith
• Craig McNally suggested that this may work itself out, because by raising it this way, it seems likely these modules won't make it into Poppy. And that maybe had they have been submitted sooner, there could have been a better chance. And Stated that we can't force teams to submit things to the Councils, especially if they are operating outside of the community
• Jenn Colt raised the concern that not being included in Poppy isn't the outcome any party wants
• Jeremy Huff stated that we should keep faith with the process and engage in the conversations about the design decision
• Craig McNally asked if there are any other volunteers to evaluate mod-lists given the potential conflict of interest. Tod Olson volunteered to take ownership of that evaluation
• Jeremy Huff advised that TAMU can provide a developer to do one of the evaluations, however we won't know till the end of the week
• Maccabee Levine volunteered to collaborate with Zak on the evaluation of ui-lists

Maccabee Levine / Tod Olson / Jakub Skoczen 

• Maccabee Levine advised that the CC did not meet this week
• Tod Olson advised that the PC discussed some internal topics around how the meetings are structured, how SIGs operate, how the PC will interact with the re-architecting proposal and what can be achieved this year. This led to the provision of the following sub-groups:
  • Meeting Hygiene and Efficiency
  • Re-architecting's impact on PC
  • Structuring SIG reports
  • Supporting Enhancements and Improvements
• Jakub Skoczen advised that the RMS group did not meet this week
• Craig McNally advised that the Security Team had a productive retrospective on the handling of embargoed vulnerabilities and how to adapt our processes to account for introduction of the RMS group

All

• Jeremy Huff advised that the TC spun up multiple sub-groups at the last meeting, however we have been unable to find volunteers for them
• Florian Gleixner advised that he and Julian Ladisch worked on the RFC for centralized vs. distributed configuration and this will be picked up in a couple of weeks time
• Marc Johnson advised that he is unaware of any progress with the architecture sub-group having missed the last meeting. And suggested that, given the community's intent to progress the re-architecting proposals, then the purpose of this group may have been superseded
• Jeremy Huff  stated that this was discussed last meeting and suggested it would be useful for the TC to have a group that was ready to engage with the re-architecting proposals
• Jenn Colt suggested that we establish a standing sub-group for the collection of RFC's that will come out of the re-architecting proposals in order to reduce the delay of forming a group for each RFC
• Craig McNally advised that a draft RFC for the applications proposal should be available within the next 4-6 weeks (as agreed at the Tri-Council meeting)
• Tod Olson agreed that there is a general interest in advancing the re-architecting proposals and the PC believes it needs to understand the impact and their role in the process, before the details of the proposals are well established
• Owen Stephens advised that the PC group will be meeting next week to outline what the group will be doing, it's priority being to get the PC into a place where it is proactive rather than reactive if these proposals are to be implemented
• Tod Olson advised that there is a role for each council to play in progressing these proposals and that we shouldn't be too concerned with overlaps across the councils
• Marc Johnson asked for the councils to work together to figure out how moving these proposals is going to work
• Craig McNally stated that he is going to progress the RFC and participate in the TC group that is brainstorming questions for the community around these proposals

Craig McNally will create a Slack vote for moving the regular TC meeting to the Monday time slot instead of Wednesday

All / Jenn Colt 

Standing agenda item to review/discuss any requested or required changes to officially supported technology lists

Previous Notes:

• 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.

Today:

• Vote today?

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

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.