2022-09-21 Meeting notes

Technical Council Sub Groups Updates

Tech Council Charter

Today:

After review, what will our rewrite process be?
Suggestion: make a subgroup to handle the rewrite.

What's the value of continuing the review in TC as a whole? Would provide a general summary of feeling about the current charge. Useful onboarding, or better to onboard with a revised charge?

Seems like a subgroup has formed: those who have actually commented

Decision: will continue with review, try to be quick and then hand to a subgroup

Review

Guiding Principles:

Need some revision per above, make these clear as they are what we go to when we are uncertain.

Motivation review:

Much language needs to change: relationship with PC is different, TC does not do resourcing, "platform" is a dubious term now.

Structure and Composition:

Much of this is redundant with FOLIO Governance Model. Should refer to that document, and retain only those items that supplement that document.

Responsibilities:

What does "own architecture" mean? When we reviewed a year ago, concluded we were not doing this well. There are some abandoned blueprint documents.

Do we think we are still responsible for this? Yes. The purpose of TC is to set some constraints or shared agreements about how the platform develops. TC does not have many options for enforcement, want compliance. Might affect how we approach the architectural guidance.

Opposing view: approach as agreement and consent rather than enforcement and compliance.

Giving teeth or power to the councils balances the weight of more powerful community members, like a check and balance. One challenge for the councils is that some voices have made decisions and councils have to retroactively accept these decisions. This creates a disincentive to talk to the councils as they may disagree. So incentive is to do first and ask permission later.

Define processes, etc.: need to be clear about project requirements v dev team domain

Maintenance of Contributor licenses, etc., CoC, etc.: Many of these seem to be for CC

Out of Scope: need to update the audience for these bullet points, broader than PC.

Key deliverables:

Much language inconsistent and out of date, some things up in discussion and may change radically.

May need two phases: short term immediate changes, then long term after other discussions resolve.

Architectural blueprint - have provided but need to update the deliverable.

RFCs: need to add ADRs

20 min

An overview was provided of the "hot topics" at WOLFcon.  It seems clear that the TC ought to be involved in these discussions/efforts;  what is the best way to participate?

• Platform minimal
• Applications/bounded contexts & application management
• Blue/green deployments
• Kafka/messaging improvements
• FOLIO governance
• API technical debt
• ???

Notes:

• Discuss if we want to try and do this during a TC meeting or schedule a dedicated meeting.
• What's working well for us?  What needs to be clarified?  
• Scope / level of detail,
• Clarify what information belongs in which section
• Is it mandatory for accompanying materials (details designs/proposals/etc.) to be on the wiki, or can they live in google docs, etc.?
• We agreed to do this sort of exercise after each RFC, but think it's worth doing this for ADRs - maybe not after each one, but periodically.
• Retro board: https://easyretro.io/publicboard/bk8DxfBbCeZIYL1pnsBPUN2xgYb2/a07d2c6b-754b-4446-8743-7f32f2911928

Introduce the topic

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

Conversation started in slack:

The Data Migration subgroup of SysOps has been struggling with how optimistic locking has interfered with batch update in Inventory. They've asked me to bring it to TC to see if there's a way to push this forward. The current open ticket is MODINVSTOR-924 Batch update with optimistic locking disabled. (This was split off from MODINVSTOR-910.)