2025-03-03 Meeting notes

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.

Maccabee Levine

Tod Olson

Jakub Skoczen

Craig McNally

• CC:  Maccabee Levine: 
  • No meeting this week
• PC: Tod Olson:
  • Implementers and UM SIGs are working on becoming familiar with the new permissions setup in Eureka. How can PC help facilitate the process?
  • Discussion with Oleksii about future release planning under Eureka & applications.
  • Reviewing PC ranked goals for 2025
• RMS Group: Jakub Skoczen: 
• Security Team: Craig McNally:
• Eureka Early Adopters:  Craig McNally:
  • Most of the Early Adopters have Kong and Keycloak deployed and are now on the registration process.

• 03 Mar 2025 - Regular TC meeting
• 06 Mar 2025 - Dedicated Discussion: RFC retrospective (tentative)
• 10 Mar 2025 - Regular TC Meeting
• - Tri-council meeting - follow-up on Eureka Adoption?
• Dedicated Discussion Topics:
  • Eureka after Trillium OST
  • Developer Documentation
  • Voting rules
    • Jenn and Craig did meet on Friday to review action items, one was to touch base with CC.  Are they dictating all voting rules, or setting basics and then councils can go further.
    • Simeon has sent proposal
  • Evaluation of the Eureka Components/evaluating exiting modules
    • How does TCR process change with Eureka/applications?
      • Craig McNally: We should get to this sooner than later.
  • Developer Advocate
  • Communication after recent TCR process changes
  • Evaluating existing modules
  • OST issues with Java21 and Gradle
  • RFC retrospective
  • Communication plan to promote updates to OST pages
  • FQM RFC (when ready)
  • Retrospective on Eureka process (when ready)

All

FQM RFC Update

• VBar Original proposal was from Wolfcon 2023. The FQM is now up to date as per Ramsons release.
• Marc Johnson We should start at public review for the FQM.
• Maccabee Levine We should be more open and public about the delays and opening this for public review.
• Jenn Colt We are starting the public review clock.

Voting rules from CC

• Marc Johnson As it currently reads, this means a motion can be passed with a single vote.
• Maccabee Levine We still have an opportunity to object to these rules if we choose to.
• Maccabee Levine Does not personally object to these rules.
• Marc Johnson The description of "Lazy Consensus" is not accurately representative of how FOLIO operates "Lazy Consensus".
• Tod Olson The current description works for me.
• Marc Johnson Is it now to time to discuss extending this?
• Jenn Colt We should focus on voting this now and extending later.
• Marc Johnson We don't have a defined period.
• Jenn Colt We can define this period every time.
• Marc Johnson Are we approving the changes or the document?
• Jenn Colt I guess we are approving the changes and effectively the document too.
• Marc Johnson We can server two terms, skip one, and then server again another two terms. Is this intended? I thoguht it was 2 terms and done and the language is not 2 terms and done.
• Jenn Colt and Tod Olson both do not understand this as to having been intended to be two terms and done.
• Maccabee Levine We might want to add an additional statement about vacancies.
• Jenn Colt Is combining multiple consecutive but separate council memberships prohibited?
• Tod Olson Being clear on the end dates should suffice (It states "up to 4 years").
• Jenn Colt Why say years if we mean terms?
• Tod Olson We will end up with the same question of: if a partial term counts.
• Marc Johnson We should be clear on "two consecutive terms on the same counsil". The rewording should be done to avoid ambiguity.
• Maccabee Levine We should get these questions answered to avoid dealing with this a year from now.
• Marc Johnson We are at the point to ask for a change, so we might not be able to accept this document today.
• Maccabee Levine We identified the issues. We should throw it back to the CC. Yes, we would not be approving this today.
• Tod Olson There seems to be a point of confusion. We could ask them about applying for a term that cannot be fully served due to these term limits.
• Jenn Colt Any council can may appoint members to fill vacant seats.
• Tod Olson That allows the council to bring iself back into full seats. It does not specify how and gives the council discretion on how to fill the seats.
• Craig McNally The language is fine.
• Marc Johnson We should then try and approve this?
• Jenn Colt We have accepted this.

On hold for now, pending clarification from the CC.

• See proposals: Voting Rule Comparisons

Straw vote about whether we should require at least 6 yes votes to accept a proposal: 4 yes, 4 no.

Last week's notes:

• Review options around quorum and whether we use majority of members present or votes cast.

Straw poll (non-binding): do we accept majority of cast (yes) or majority of TC members present (no):

• Yes: 3
• No: 6
• Abstentions: 2

Next step: define a set of straw polls we want to ask, then we can execute those all at once and hopefully narrow in on a decision.

Discussion today:

Marc Johnson problem with straw polls when the number of votes minus abstentions is less than 6

Ingolf Kuss we should think about deciding first weather we want to have slack votes or not

Jenn Colt should we enable slack voting by request before the conduction of a vote?

Jenn Colt 10:07 AM
For https://docs.google.com/spreadsheets/d/1E6mjwFCGzvv-B-exkvH5g6zwR4VR6Maoei7KL89nP4s/edit?gid=0#gid=0
https://folio-org.atlassian.net/wiki/spaces/TC/pages/852852742/0011-Folio+Query+Machine+FQM

Jakub Skoczen  to  Everyone 10:12 AM
Sorry for being late, internal meeting

Jenn Colt  to  Everyone 10:12 AM
Do you need to update anything from RMS?

Jenn Colt 10:26 AM
We could link to this instead https://www.apache.org/foundation/glossary.html#LazyConsensus

Maccabee Levine 10:42 AM
I agree with Jenn
"may only be elected to two consecutive terms".  elected so it doesn't count appointments

Review decisions that are in progress.  Can any of them be accepted?  rejected?

Currently there is a PoC, developed by Maccabee Levine, of a utility to catalog Github PRs that have been labeled with the "breaking change" label. We would like to get developer feedback on the feasibility of this label being used more often, and the usefulness of this utility. 

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.

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.