Date
Attendees
...
| Time | Item | Who | Notes |
|---|---|---|---|
| 1 min | Scribe | All | Jeremy Huff is next, followed by Marc Johnson |
| 20-30 min | TCR Board Review | All | Reminder: 27th January is the Deadline for acceptance of new modules by Technical Council
TCR 22 Marc Johnson : There were 4 evaluations done during the span of this evaluation window. There is no criteria that Marc is unsure about in this final iteration. Craig McNally : The last we heard the module was incomplete. Particularly module endpoints not being connected to implementations. Marc Johnson Marc Johnson: The endpoints described in the module descriptor have been connected to implementations. Craig McNally Craig McNally: Are there still any issues with the accuracy of the personal information disclosure form. Marc Johnson Marc Johnson: The team implemented changes to the personal data disclosure form based on feedback given during the evaluation processes. The criteria surrounding permission names may need to be clarified by the new module evaluation subgroup. We should also add criteria that ensures that the module implements the criteria it says it does. The module was approved. Marc Johnson Marc Johnson: We should avoid future reviews which are of the level of implementation that this module was in when the evaluation started. TCR 24 Jeremy Huff: There are two areas open for discussion, 1) the addition of the "mod" prefix to avoid name collision with exiting permissions, 2) the presence of vertx dependencies that are not explicitly listed on the list of approved technologies. Jeremy is of the opinion that neither of these should prohibit Mod Settings from being approved. There were no objections to approving the module despite either of these configurations. Florian Gleixner: There is an ongoing discussion about centralized vs distributed configuration, should this discussion prohibit the approval of this module Jeremy Huff: The evaluation team did not feel that this conversation was relevant to the technical approval of the module Florian Gleixner: Should a note be attached to the review reflecting this Jeremy Huff : Agrees to add the additional section for notes, and modify the criteria to show that the module has been accepted Marc Johnson: The PC has approved the module, but not based on any sort of architectural Ingolf Kuss: Isn't there a subgroup in place to talk about this configuration issue? Craig McNally: Provided the historical context for the decision to allow Mike Taylor and his team to continue with their work The module was approved |
| 10-15 min | Technical Council Sub Groups Updates | All | Technical Goals and Objectives Tod Olson : There was a meeting were feedback was given. There are some changes that Tod is intending to make in response to those Breaking Changes Jeremy Huff: Completed the term definitions section. Some copy editing remains before submitting the RFC TC Process Jeremy Huff: Action Items have been created and assigned. Charter Revisions Jenn Colt: We have a revision to bring to the TC, and will address later in this meeting |
| 10 min | TC Charter Review |
Craig McNally: We will review the draft in TC and next step is to determine if this ready for the CC. Mark Veksler: What is meant by the operational health of the reference environment Craig McNally: This language was already in the charter Marc Johnson: Didn't we ask the CC about this? Craig McNally: We did, and were told that it is unknown what this term means Jenn Colt: The CC said the TC should decide what that term means. Jen suggest that we accept this term as it is and define it over time. Mark Veksler: Operational health might include the ability to release on time. Is this part of the TC's responsibility? Craig McNally: This line is adding ambiguity, maybe it should be struck Tod Olson: Suggests restoring the word "infrastructure" Mark Veksler: If we say that the TC is responsible for maintaining the development environments, who is responsible for this? Craig McNally: Maybe we should replace "maintain" with "provide oversight" Marc Johnson: We did not want our language to be limited to the provision of opinions. We need to be mindful of how the language in these charters effect the ability of a council to act and make decisions. There was some discussion about who is responsibly to determine who is responsible for reference environments, and it was decided that it is the who makes such decisions CC. Jenn Colt: We can maybe change operational to technical
Craig McNally: We should put this on the additional topics agenda for further discussion | |
| 5-10 min | RFCs | All | RFC to review from Olamide: https://github.com/folio-org/rfcs/pull/4 Previous Notes:
Today:
Craig McNally Has a subgroup has been formed? Marc Johnson not yet Craig McNally Will follow up with this to ensure that the subgroup is formed |
| 1 min | DR-000032 - Splitting Database Read/Write Traffics in RMB | FYI: DRAFT decision record: DR-000032 - Splitting Database Read/Write Traffics in RMB Martin Tran will be joining us next week for a short presentation and DR review. | |
| 1 min | Upcoming meetings |
| |
| * | Decision Log Review | Craig McNally /All | This was not discussed due to time. Moved to discussion for next week.
|
Topic Backlog | |||
20 min | WOLFcon Hot Topics | All | An overview was provided of the "hot topics" at WOLFcon. It seems clear that the TC ought to be involved in these discussions/efforts; what is the best way to participate?
Notes: Deferred |
| Cyber Resilience Act | Craig McNally /All | From Craig McNally in #tech-council: This was brought to my attention earlier today...
Today: Deferred | |
| Ease of Installing FOLIO | All / Ian Walls | From last week:
Today:
| |
| Revisiting FOLIO Governance | All / Ian Walls | Slack discussion: Revisiting FOLIO Governance | |
...