2021-10-13 Meeting notes

Date

Attendees

Discussion items

TimeItemWhoNotes
1 minScribeAll

Tod Olsonis next in the list, followed by Philip Robinson

2 min

Review outstanding action itemsAll


Decide 1 year/2 year termsAllBack 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
    • Technical Designs and Decisions
    • 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
    • Call to revisit the RFC process
      • Process documented in README.md in https://github.com/folio-org/rfcs
      • Take review as homework? 
      • Concern is that this will not be effective to do this in TC, but more effective to have a small group review
  • Goal: define a decision-making process for technical decisions.
    • Broad goal is to have a decision-making process for the project, narrower goal for volunteer(s) is to make a proposal that moves us forward.
    • Presentation would include the scope of the process
    • Who is the target audience, who makes the proposal? 
    • Check-in: 1 week; Deadline: 2 weeks
  • Actions
    • VBar can commit to re-present the RFC process next week
    • Jakub Skoczen will try to define what we are trying to accomplish
< 5 minutesExternal Code Submissions
  • Ongoing work on Acceptance Criteria and Processes (submission, evaluation, etc.)
    • Has the Acceptance Criteria v1.0 been published somewhere yet?  What about references/links in other places.
      • Will pick a Github repo and deposit it later (Jakub)
      • Tod Olson RFC might be a good choice
    • Agree on short and long term goals, will continue to work on:
      • Define processes for submission, evaluation, review, feedback, acceptance
      • Improve the AC with more verifiable criteria, links to supporting documentation, etc.
      • Time frame: Ian and Jakub will take a look at Lotus dates and inform the team next week
    • LDP Review: reach out to Jeremy Huff and Nassib Nassar and sort out this by today

Jakub Skoczen will create a new GitHub repo for TC

< 5 minutesCouncil Goals/ObjectivesAll

Follow-up from previous meetings...

Previous notes:

From Mike Gorrell:

I have created a clean copy of what the Community Council created to identify which FOLIO Goals/Objectives were under the purview of the CC. We also took a stab at what thought would be handled by PC or TC. Please feel free to give us feedback/etc. https://docs.google.com/document/d/17jVxW2XEK2bRSpXG9_FvdVtgqDfCTeKKM5h49IIhmRw/edit#heading=h.m2gdb67ibe1x. and use for your planning purposes.

Update from Tod OlsonJeremy HuffCraig McNally who met to discuss this last Friday.

  • The Friday meetings will be at 11am EST, please join if you can.

Check-out Performance 

Follow-up from previous meetings...

Proposal from Marc Johnson: https://folio-org.atlassian.net/wiki/display/~marcjohnson/Check+Out+Performance

Marc Johnson was asked to make a proposal for checking out performance; draft document is available by the first link above. Feedback is appreciated

There's a link to PTF analysis from the first mentioned doc


Check-out Performance 

Counter-proposal from Julian Ladisch: https://folio-org.atlassian.net/wiki/display/DD/Check+Out+Performance

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 PerformanceAll

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