2022-09-28 Meeting notes

TCR-16: (mod-ui-calendar): Zak Burke: meets all criteria, but is bound to mod-calendar TCR-17 so it makes sense to evaluate TCR-17 first.

TCR-15: Zak: Does not meet several criteria. Should not be accepted at the moment.

Owen Stevens: Work is identified.

Jeremy Huff: Rejection is just a first answer. Does not start the review process from zero.

Owen and others: Submission for approval should not start when all acceptance criteria are fulfilled. Feedback is fruitful.

Changed status to draft without voting. Will be submitted from Owen soon.

TCR-6: Jeremy Huff: is in review.

Craig and Jeremy: Acceptance Criteria and Template should be reviewed.

Craig wants feedback for "Folio can do better" in a google doc.

Discussion about modules marked as "new in Nolana": Should we be strict?

Reminder to elicit feedback from three people on the top three things they think FOLIO can do better, and get them added to the document:

https://folio-project.slack.com/files/U5Y684C8M/F043RLB4STG/list_of_things_that_could_be_better_about_folio

There's a template at the top of the doc you can copy/paste into your own section, then add your informant's feedback.

Technical Council Sub Groups Updates

Update from Vijay: 

I did incorporate some of the feedback that got in relation to Managing Tools/Dependencies. I have a couple of outstanding questions related to the Feedback. As a result, I am meeting with Marc and Jacub this Friday to discuss that further and wrap it up.

Tech Council Charter

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