| Time | Item | Who | Notes |
|---|
| 1 min | Scribe | All | Steffen Köhler is the next in the list, followed by Chulin Meng |
5 min | Review outstanding action items | All | Zak Burke no progress on "identify categories of decisions the TC makes and suggest applicable processes" |
| 3 min | Dec 29th Meeting | All | Given vacations/holidays, should we just cancel the meeting on Dec. 29th? |
| 10-15 min | TCR Board Review | All | - 2 new Submissions
- both incomplete, both about multiple modules (package deal), postponed yet
- Zak Burke therefore TCRs should be split, each per module
- Owen Stephens , Marc Johnson , VBar mention a timing issue with these process
|
| 10-15 min | mod-inventory-update Evaluation Review | | I hear that the evaluation is completed, to be presented by Mikhail Fokanov - evaluation results are stored in tech-councils git-repository
- missing integration-tests written in karate (unacceptable)
- moreover some comments about this module
- could be integrated in another backend module...
in addtion proposals for evaluation process in general (see comments on TCR-5 on issues.folio.org) : - new stage "architectural fit" after the technical evaluation
- check for module doing the same thing / avoid duplication
- check, whether the functionality should be implemented inside one of existing module
- check for data consistency issues
Discussion: Owen Stephens , Marc Johnson , ... - some points (duplication checks) in responsibility of other councils (product council)
- has mod-inventory-update functionality that are better served elsewhere?
- special use case for libraries not using source record storage, so now (Charlotte Whitt )
- Marc Johnson Should we decide according to our guide line which has been developed during the review of the ldp?
- So the conclusion for today should be "Failed, because of the missing karate tests"
- Jakub Skoczen indicates that the tests must be in karate if they exist, needs to be cleared
Vote about this: 6 yes, accepted
|
| 5-10 min | New Module Technical Evaluation Previously: "External Code Submissions" | | Quick update from the sub-group? Quick update from the cross-council group for defining the end-to-end process? |
| 3 min | Council Goals/Objectives | All | |
| 20 min (Time permitting & Depending on attendance) | Technical Decision Making Process | | 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
Additional Context: For Today: - We had homework to review Jakub Skoczen's document and provide feedback/questions/comments.
- Does the RFC proposal meet the purpose outlined here in this document?
- Are there other proposals for a decision making process (maybe that borrow parts of the RFC process)?
- Last time discussed: "need some feedback, will come back next week". Skipped last week due to low attendance.
Postponing, need more feedback on document.
Jeremy Huff asked which decisions would be covered by this topic? Craig McNally agreed that a policy on which decisions fit into this process is an important part of this topic.
Jeremy Huff suggested that we form a working group to define more detail around this topic. Craig McNally agreed that was a good idea or alternatively, we need other proposals
Tod Olson stated that he felt the RFC process is a good fit for our needs.
Zak Burke suggested it would be good to have a workflow for what kinds of decisions need which decision making process and guidelines for expectations around our decisions. Craig McNally agreed, and acknowledged that one of the challenges with each process is deciding on it's applicability
Zak Burke volunteered to identify categories of decisions the TC makes and suggest applicable processes |
20 min (Time permitting and Depending on attendance) | Participation and Attendance Expectations | All | - Low attendance/participation from some members is becoming concerning - it's probably worth aligning on expectations.
- Use of proxies?
- How to handle low attendance
- Cancel the meeting?
- Still meet and make progress on things that don't require decisions to be made, e.g. review proposals and provide feedback, at least go through the usual updates
- ...
Discussion: - Strong preferences for not cancelling meetings.
- Comments in favor of leaning on proxies, but not too much.
- Some projects (e.g. NPM) have minimal requirements for attendance, not clear we want to formalize this.
- Need more participation outside of meeting, there is more to be done than 1 hour per week in meeting.
- How to set expectations about participation?
- Probably best to set vague expectations to promote useful participation.
- Examples of participation might be useful
- Setting metrics is probably neither practical nor has the right tone.
- Baseline
- Encouragement at all meetings is encouraged, and if cannot make a meeting send a proxy
- Happy to use half-plus-one to make decisions, and lean on lazy consensus unless there is a call for a vote
- Homework!
- Ideas for broad expectations:
See 2021-12-01 Meeting notes for additional details. |
Time permitting |
|
| - Another meeting rules thing: should we have a formal policy/discussion about attendance, discussion, and decision making when attendance is low/less than half?
|