2022-12-07 Meeting notes

Ankita Sen is next, followed by Jakub Skoczen 

Maccabee Levine filled in last week.

All

No news.

Reminder:  27th January is the Deadline for acceptance of new modules by Technical Council

No news.

All

Translations Subgroup: Zak Burke - Didn't meet this week. The summary document will be ready by next week with the gist of the discussions and how to move forward with this.

Controlling AWS Hsoting Costs: No news. Pushed till next week.

Breaking Changes: Jeremy Huff - Took a break due to Thanksgiving holidays and Ankita Sen being away. She has created a draft RFC and submitted for feedback from the subgroup. The calendar event lapsed so scheduling conflicts were there this week. Will have more updates next week.

Improve the TCR Process  : Jeremy Huff -Scheduling conflicts so was away. Marc Johnson - First retrospectives have been decided and agreed upon. Craig McNally - Retrospectives have been created and scheduled and boards have been created.

Tech Council Charter Revisions : Jenn Colt -Had our first meeting. Significant news is that the 2018 TC charter has been superceeded by the CC's unveiling of the new governance and a new charter for TC is already made available. Changes to the 2018 Charter have been started according to the new available charter.

ADR Process Improvements : Radhakrishnan Gopalakrishnan - Good progress has been made and migration is underway and at least 10 of the collective decisions made are being migrated now. Once the migration are done a need of volunteers will arise for doing a quick sanity check on them. A new section has been added describing steps on how to create ADR and seek approval for them.

Craig McNally 

Previous:

Mike Taylor is looking for "buy-in" from the TC on his proposed changes to mod-configuration. See Fixing the security problem in mod-configuration for proposal and Configuration and customization in FOLIO for context.

How do we evaluate this w/o considering the bigger picture (distributed configuration vs centralized configuration vs both)?

• Concern registered that this creates more confusion unless there is a concrete plan to migrate

He points out inconsistency in configuration APIs, does this proposal address that?

Is there a gap in our decision making processes?  There's sentiment that the RFC process is too "heavy".

• Seems like this is already a proto-RFC and this is exactly the sort of wide-reaching thing we would want to go through the RFC process.
• The off-putting thing is how long the RFC process takes.
• Points to the challenge of getting people to come to the TC for a decision when they are blocked. Effectively, a team needs to bring a proposal to TC one full release cycle before the work can be done.
• There's a wish to accelerate the process, but that seems optimistic.
• Impression is that he's most concerned about the time issue and ongoing effort that goes into the RFC process.
• Noting that under our current processes we cannot prevent him from making these changes and using them for himself.
• There does seem to be agreement that this is a concern, and that there are multiple reasons to get a handle on the configuration situation.
  • Was raised sometime earlier and discussed in core-platform, but was deprioritized for some reason. Unclear why.
• Does this conflict with an earlier decision, possibly undocumented, about moving toward distributed configuration?
• Possibly endorse tentatively, make changes to the API, and then go through RFC process.
  • Must be prepared to decide differently, that we might decide to move to distributed after all.
  • If long-term decision is to move to central configuration, then we need to coax people into migrating

Decision:

• Mike can go ahead with changes to mod-configuration if he needs in order to unblock his work
• TC is not formally approving the proposal at this time, but will move in parallel with an RFC process.
• TC needs someone to champion the RFC and shepherd it, does not need to be a current TC member but should be familiar with the RFC process. Have tentative volunteer but will revisit next week.
• Following RFC process, will need to socialize outcome with development teams.

Marc Johnson 

Introduce the topic

• What do we want to get out of this conversation?
• Does this require a subgroup or individual to generate a proposal?

Notes Today: 

Craig McNally - Have noticed this during the TCR-0009. Brainstorming is suggested top make some progress and get some ideas going about this topic. One first step is introducing recommended and optional step into our Process for reaching out to the TC before development of new module start. It is a multi faceted thing and not simple. It might be helpful to look at concrete example that TCR-0009 brought to the table. The topic is more subjective.

Zak Burke - Current process of Technical Review focuses on code correctness and maintainability, but on other hand there are Sys admins that treats the modules as black box and don't care about the code correctness, the language it is coded in. How do we want to think about the module the community owns? Is it easier if they are considered as a black box but do we want to compromise on the maintainability? Maybe we can reframe this as module feedback process ?

Marc Johnson - Our existing policies for reviewing modules are very specific and is as little ambiguous as possible. We don't really have a proper definition of what exactly the architecture is. None of the review process has this exact thing defined. Uniformity is missing. TC should review during the first TCR process to decide whether a new module has any architectural impact. It can be a trigger point to work into the blue print work.

Craig McNally /All

From Craig McNally in #tech-council:

This was brought to my attention earlier today...
https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/
While it's still just a proposal, I think FOLIO should keep an eye on, and maybe even try to get ahead of in anticipation of this.  I will add it to the agenda for next week's meeting.  This is a short read that does a decent job of laying it all out.  Please take a look prior to next Wednesday.  Thanks! 

• Have folks had a chance to read through any of this?
• What, if anything do we think the TC should do about this?
  • Raise awareness among other councils?
  • Seek legal advice in anticipation of this being passed?
  • Is there anything else we want to do to be more prepared for this in the event it does get passed?

Today: Deferred

Tod Olson 

All / Ian Walls 

From last week:

• Ease of installing/deploying FOLIO - Ian Walls , Marc Johnson , Jeremy Huff
  •  Primary task the Tc would take on by making FOLIO easier to get up and running. Would also reduce AWS costs so that the money coming from Membership groups can be flowed to other aspects of FOLIO. Tc is the best equipped group to decide on how to make installing and deploying Folio easier and cheaper.
  • Craig McNally - Brainstorming open ended session with Ian Walls and then discuss further before or after WOLFcon depending on the brainstorming session. Ian Walls and Tod Olson to frame the topics of discussion for the brainstorming. 

Today:

• Probably defer, but keep on the agenda so we don't lose track of this...

All / Ian Walls 

Slack discussion:  Revisiting FOLIO Governance 

• • Ian Walls - should be best discussed in cross council meeting possibly at WOLFcon. Idea to was bring this up at a high community level not necessarily the Pc or TC. Doesn't need to be on TC agenda next week. Aspects to be discussed at WOLFcon.
  • See also:  messages to PC and CC council channels