Back in July we asked Zak Burke to create a reminder for us to discuss this...
Technical Decision Making Process
All
This is a carry-over from last week.
The tech leads group not being a decision making body
Whether it's realistic and/or desirable for the TC to make every technical decision
There was some overlap here with the external code submission topic
Related - in the wake of last week's slack vote:
Revisit voting rules:
quorum: 8 (tie is no, so minimum 5 votes to pass)
simple majority: yes
of vote casted (including abstentions): yes
Abstain: Yes
Delegate: Yes
voting via slack: No, it has to be in person only
Future for Tech Leads Group? Who makes technical decisions, how?
Brainstorming on how to make technical decisions
TC meets one hour per week, not all decisions can bubble up to TC.
Tech Leads doesn't have much structure, nor does it have the power to make things stick.
Example: coding standards. How do we cause a decision about that be made?
Original design of Tech Leads/TC relationship was that if there was dispute it would go to TC. This is intended for the strategy decisions, but winds up with low-level decisions being bumped to TC.
Tensions:
Need designs to be documented, but taking time for review interfered with timeline of getting things done
Appears teams often don't review technical decision log before moving ahead
Problem: Need to have a documented, common understanding of how we do things in FOLIO
How do we do this with Tech Leads and not re-invent the TC?
Tech Leads originally for technical consultation
Question: what level of standardization do we want/need?
There is some overlap with Acceptance Requirements
Tech Leads for tactical decisions and TC for strategic?
Zak Burke sees a need for more standardization, decisions that are cheap for an individual team or developer often become costly for the project. Suggests a process for one group to deal with the tactical and another to deal with strategic.
Do we have consensus that TC is strategic and Tech Lead is tactical?
Maybe not, there's a question of scope. Maybe this is the division at the Platform level
Revive the RFC process?
Tension:
More rules make it harder for external teams to make contributions, but make things more consistent/smoother within the project
How are topics taken to the TC for a decision?
The TC is not good at taking a broad topic, having a discussion, and coming to a decision in a reasonable amount of time
Much better when there is a concrete proposal that the TC and review and respond to.
RFC process could be revisited.
Need a standard format/process
Could be used for both tactical and strategic decisions
The Capacity Planning Team has determined that we should proceed with the caching approach. The feature UXPROD-3317 "Improve checkout performance by caching data" and 19 stories with priority P1 (linked from the UXPROD-3317 feature) have been created.
Upgrade/Migration Script Performance
All
We've run into situations where migration/upgrade scripts take a very long time to complete, which is problematic. The TC should consider defining some criteria around this... Possibly a phased approach over the course of the next few releases?
Overlaps with the acceptance criteria topic as it applies to modules already part of the official FOLIO release.
Time permitting
TC charter review
All
Action items
Jakub Skoczen to create a Tech Council repo and move Acceptance Requirements document