2022-09-28 Meeting notes

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll
15-20 minTCR Board Review

All

Zak Burke: TCR-18 (ui-gobi-settings):

Meets all criteria, but probably Zak had old version of acceptance criteria. Seems, criteria were updated, but template not.

The template was reworked to clarify and simplify criteria, but no fundamental change of the criteria are in the new template. All green, so merged and moved to done without voting.


Ingolf Kuss: Where can i find the acceptance criteria: New Module Technical Evaluations but template has to be updated.


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-17:

Marc Johnson: Permissions are unusual. Discussed with developers, criteria are maybe not flexible enough. Small possibility of privilege escalation. But impact is not worth to hold the module back. A discussion about acceptance criteria and strictness has to be conducted sometime later.

Craig: If the problem does not give much permissions, i agree with Marc

Marc: Permission does not affect UI.

Discussion between Marc, Jeremy, Zak and others about how strict one should be on criteria and the consequences for developers if TCRs are rejected.

Zak: Permissions from UI side do not look unusual, agrees with Marc, that these unusual permissions dont have a practical effect.

Marc: Permission is not visible, use of this permission is mod-circulation

Jeremy Huff: Consistency in criteria between modules is good, and therefore strict is good, but here we could make an exception. It is good, that this case is discussed and documented. Flexibility in Criteria is important.

Anton: Should accept, but make a list for developers what to fix?

Marc: Agree with intent, but with mod-ldp this did not work at all. Developers explained why they did it that way, so no list to fix.

Craig: Vote for Acceptance together with TCR-16

6 Votes for yes, none for no.


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?



We did not get to any of the following items due to the amount of time spent on TCR-related discussions.
-RFCsAll

Nothing to review

1 minThings FOLIO could do betterAll

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.

10-15 min

Technical Council Sub Groups Updates

All



1 minManaging Dependencies

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.

20 min

Tech Council Charter

All

Previous:

Members were asked to review the TC charter in preparation for today's discussion.  

  • Go through the charter together?
  • Are there specific areas of the charter we should focus on?
  • Is anything that's missing, or should be removed?

Notes: TC charter has been updated recently, how would the TC like to review it?

Jeremy Huff Was it written by TC or by someone else? - Craig McNally It was written by TC?

Craig McNally Let's create a draft version, discuss it, communicate to other councils before publishing

Tod Olson A comment to Guiding Principles .... (smth that should be explicitly stated as a GP) - Tod will add a comment to the doc

Some conversation followed.. some comments were added to the doc itself

Review and comments from TC members are welcome

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

Time Permitting

20 min

WOLFcon Hot TopicsAll

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:

5-10 minTools/Dependencies Versions

Previous:


Today:

???Technology Changes & Releases

Previous:

  • How/when to make significant technology changes in coordination with the release schedules of other tools, e.g. keeping in sync with Node LTS releases, or Java 17 or Postgres 14, etc. 
    • May be overlapping with the Tools/dependency versions (see above)
    • Marc Johnson - It would be useful to relate the changes to match the release schedules
    • See also:  messages in TC channel

Today:

10 minRetrospective on the ADR Process
  • 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
Topic Backlog

How can/should the TC weigh in on the architectural impact of new modules?

Introduce the topic

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

Optimistic Locking interfering with batch update in inventory

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


Ease of Installing FOLIO

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

Revisiting FOLIO Governance

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

Action Items

  •