2021-10-20 Meeting notes

1 min

Scribe

All

@Philip Robinson is next in the list, followed by @Jakub Skoczen

2 min

Review outstanding action items

All

• @Mark Veksler  No updates from the Cap Planning team

• External code submissions - @Jakub Skoczencreated the GitHub repo

5 min

Security Team Personnel Changes

All

@Mike Gorrell is stepping down from his role on the FOLIO Security team.  @Jakub Skoczen has be nominated by the team to fill his spot.  A formal process for this hasn't been defined yet, but we wanted to raise this here for awareness and to give folks a chance to weigh in on the choice.

Two questions:

1. Any objections to the team's selection? None raised at the meeting.

2. Any objections to the process we used for member replacement?  If not, the security team will document the process so it's clear how this should be handled going forward. No objections raised, so the security team will document the process.

35 min

External Code Submissions

@Ian Walls/All

Discussion ran much longer than the time originally allocated.

• mod-inventory-update eval for Lotus... https://folio-project.slack.com/archives/CAQ7L02PP/p1634659952419300, https://github.com/folio-org/mod-inventory-update

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

    • @Charlotte Whitt said it would be helpful to have an official wiki page for the criteria. @Anton Emelianov (Deactivated) agreed, and the page should list the sequence of steps for a new module to be accepted for release. @Craig McNallymentioned that the TC has been working this for a while and will continue to focus on it.

  • 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 Walls and @Jakub Skoczen will take a look at Lotus dates and inform the team next week

      • @Ian Walls needs clear timelines from the release team, otherwise the feature has to wait until the following release. Ian needs an addition to the timeline that explicitly states which date is the TC external code review deadline.

      • @Anton Emelianov (Deactivated) will join the Friday meeting focusing on a resolution to this.

      • Timeline: Lotus (R1 2022)

  • @Zak Burke LDP approval came to TC from PC and would expect future requests to come from PC rather than directly from contributors. @Owen Stephens  and @Brooks Travis agreed. @Charlotte Whitt said the module has already been approved by the PC.

  • @VBar there's a race condition where we have a series of incoming technical review requests, but the processes haven't been finalized. We should have a moratorium on evaluations temporarily until the processes are complete. @Craig McNally agreed. @Jeremy Huffasked does that mean no new modules can get through until the process is finished?

  • @Brooks Travis considers modules hosted on the project GitHub as approved by the PC. The PC is going to get a handle on what gets added to the project GitHub. This is the distinction between the LDP app and mod-inventory-update, and mod-inn-reach. His understanding of what the PC wants is the TC's recommendations as to the viability of external contributions, but the decision is still PC's.

  • @Marc Johnson feels that the TC is mixing up at least 2 processes: accepting modules into the community, and including them in the official distribution.

  • @Owen Stephens noted in chat that the PC said it wanted LDP app to be part of the FOLIO product, but that may not be relevant. There should be some kind of sign-off process from PC. @Brooks Travisagreed and suggested that it be raised at PC again to clarify the process for acceptance. @Owen Stephensclarified that he was making his point generally, not questioning whether the PC sign-off happened for mod-inventory-update in particular.

  • @Zak Burke asked whether TC should distinguish between internal submissions and external.

  • @Charlotte Whitt needed to leave early and said that @Kirstin Kemner-Heek will attend in her place for the remainder of the meeting, as PC rep and as stakeholder for mod-inventory-update.

  • @Marc Johnson asks are the TC being asked to establish a process for acceptance into the community, into the distribution, or both?

@Jakub Skoczen  created the new GitHub repo for the TC.

The potential Kiwi review phases are past, so TC will focus on Lotus forward.

@Craig McNally posited that we're probably all on the same page about needing to agree on the standard review processes.

@Mark Veksler suggested that we need to be date-driven with clear timelines on when module evaluations need to completed. 

@Brooks Travis proposed coming up with the deadline date when the subgroup meets on Friday.

@Marc Johnson reminded us how stressful and confusing it was to rush through a review before having finalized criteria.

@Mark Veksler suggested agreeing on a due date for finalization on the TC proposal process, when the subgroup meets Friday. The subgroup would propose that date and send it back to the TC for approval. @Craig McNally agreed with this idea. @Anton Emelianov (Deactivated) added that it should include clarity on the workflow around the submission process.

@Brooks Travis recommended not tying this process to actual code release processes.

@Craig McNally said all we're looking for is a date, which could be in Spring etc. No need to rush.

3 min

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.

• The Friday meetings will be at 11am EST, please join if you can. Contact the above folks if you'd like to attend.

5 min

Decide 1 year/2 year terms

All

Deferred last week due to insufficient TC attendees.

Back in July we asked @Zak Burke to create a reminder for us to discuss this... 

• Q: Should half of the TC serve 1-year terms, the rest 2-year terms? Other councils do this.

  • If splitting, who would serve 1, who 2?

• @Jeremy Huff asked whether there are term limits.

• @Tod Olson will check the founding documents for clarification.

• @VBar reported in chat that "Council seats will have term limits - no individual may occupy a seat for more than 4 consecutive years on any council (2 terms)", emphasis on "consecutive".

• @Jeremy Huff and @Zak Burke volunteered for 1 year.

• See: Technical Council Membership History

5 min

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. 

Additional Context: 2021-10-13 Meeting notes

• Actions from last week:

  • @VBar can commit to re-present the RFC process next week

  • @Jakub Skoczen drafted a definition of what we are trying to accomplish → See here . TC members are commenting on the proposal within the document.

• The TC will review the document and provide feedback.

• RFC process is documented here: https://github.com/folio-org/rfcs

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