Page Comparison

Marc Johnson is next, followed by Ingolf Kuss 

All

• 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
  
  • Update on this?
• Relevant dates:
  • • 22 Sep 2023 - Deadline for acceptance of new modules by Technical Council at Poppy (R2 2023)

Maccabee Levine / Tod Olson / Jakub Skoczen 

• Updates from CC (Maccabee Levine): 
• Updates from PC (Tod Olson ): from 2023-08-31 Product Council Agenda and Meeting Notes: 

  • Follow up from WOLFCon PC shoulder meeting "what can we do this year?" discussion
    https://easyretro.io/publicboard/0ALmBRbRDFgKpGdILQIAZio6Nvq1/50ab1c13-8eb5-417a-abff-5742305828de

    Forming subgroups:

    • Meeting Hygiene and Efficiency
    • Re-architecting's impact on PC
    • Structuring SIG reports
    • Supporting Enhancements and Improvements
  • See also Product Council Sub Groups
• Updates from Release Management Stakeholder Group (Jakub Skoczen ): 
• Updates from the Security Team: 

All

Last week's notes:

• 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