| | | |
|---|
1 min | Scribe | All | @Tod Olsonis next in the list, followed by @Philip Robinson |
2 min | Review outstanding action items | All | |
| Decide 1 year/2 year terms | All | 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. Related - in the wake of last week's slack vote: 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 Question: what level of standardization do we want/need? 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? Revive the RFC process? Tension: 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
|
< 5 minutes | External Code Submissions | @Ian Walls/All | @Jakub Skoczen will create a new GitHub repo for TC |
< 5 minutes | Council Goals/Objectives | All | 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 Olson, @Jeremy Huff, @Craig McNally who met to discuss this last Friday. |
| Check-out Performance | @Marc Johnson | 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 | @Julian Ladisch | 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 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 | |