Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
The meeting focused on reviewing TCR (Technical Council Review) 42, which involves evaluating a specific module for approval.
The presenter presenters of TCR 42 admitted to being slightly behind schedule due to personal reasons, which led to a delay in finalizing the review.
A few outstanding issues were identified during the review, including a missing Product Council (PC) approval and an update to the module’s README file, which the development team had committed to updating.
Module Review and Approval Process:
A critical discussion point was whether the TC (Technical Council) should proceed with approving the module before the PC has conducted its review. The standard process usually requires PC’s functionality review before TC’s technical evaluation.
It was noted that the back-end of this module had already been approved in a previous meeting, raising questions about the consistency and timing of the approval process.
Concerns were raised about the implications of approving a module without PC’s review, potentially setting a precedent that might affect the governance process.
Specific Issues Identified:
Stripe Version: There was a discrepancy regarding the Stripe version being used. The TCR documentation initially stated that Stripe 9.2 was required, but the development team clarified they were using version 9.1.4. This was flagged as an issue but was deemed not significant enough to block approval.
Product Council Approval: The TCR review included a checkbox for PC approval, which had not been completed. The team discussed whether to wait for PC to review the module before moving forward with TC approval.
Suggestions and Next Steps:
It was suggested that the presenter follow up with the PC to expedite their review, allowing for the TCR to be finalized.
There was also a suggestion to develop more comprehensive documentation or guidelines for TCR reviewers, particularly around areas like license checking and accessibility, to ensure consistency and clarity in the review process.
The decision was made to hold off on approving TCR 42 until the outstanding issues were resolved, particularly the PC approval.
Overall Reflection:
The discussion highlighted the importance of following the established process for module approval, ensuring that both technical and functional evaluations are completed before any final decisions are made.
There was a recognition that the process might need to be clarified or adjusted to prevent similar issues in the future, particularly around the coordination between TC and PC reviews.
The static code analysis subgroup recently held a meeting, though attendance was low, with only two members (Julian and another member) participating.
The primary focus of the meeting was to discuss improvements to the subgroup's acceptance criteria, which led to some disagreements within the group.
Scope and Definition Challenges:
A significant part of the discussion revolved around defining the scope of the static code analysis subgroup. There was some confusion and disagreement about what exactly falls under "static code analysis."
Areas of Debate:
Inclusion of Unit and Integration Tests: One of the contentious points was whether unit tests and integration tests should be included in the static code analysis subgroup’s scope. Some members felt that these tests are closely related to static code analysis because they assess the functionality of the code, while others argued that these tests are not static in nature and should be considered separately.
Definition of Static Code Analysis: The discussion also touched on what constitutes static code analysis itself. Traditionally, this includes identifying code smells, code duplication, and security issues through tools like SonarQube. The subgroup is trying to determine whether its scope should be broadened to include other forms of testing and analysis.
Next Steps:
It was concluded that these discussions should be brought to the broader Technical Council (TC) for further input and clarification. The subgroup recognized that defining the scope is crucial before making any progress on their tasks.
The group decided to continue these discussions asynchronously (via Slack or email) and revisit the topic in the next TC meeting when more members could be present to provide input.
Developer Documentation Subgroup
Ongoing Progress:
The developer documentation subgroup is focused on creating a comprehensive developer manual that will serve as a key resource for both new and existing developers.
The subgroup reported that they have successfully established the framework and strategy for the manual. The next phase involves populating the manual with content, a task that will require significant community involvement.
Challenges and Focus Areas:
Community Involvement: The subgroup identified that one of their biggest challenges is securing active participation from the community in maintaining and updating the documentation. They emphasized that without widespread community engagement, the developer manual project is unlikely to succeed.
Roles and Responsibilities: The subgroup is working on identifying different roles that could contribute to the documentation efforts. They noted that not all tasks require deep technical knowledge, and there are opportunities for non-developers to assist with the project.
Strategic Meetings: Jeremy and Maccabee, key members of the subgroup, have been organizing meetings with various stakeholders to discuss how to effectively involve developers and other community members in the documentation process. They have already met with a couple of key figures (Kalila and Olamide) to gather initial feedback and plan to continue these meetings.
Implementation Strategy:
Initial Steps: The subgroup has started filling in some sections of the manual with content that needs to be written from scratch. This content will serve as a foundation as they work to gather and migrate existing documentation into the new framework.
Tools and Resources: The subgroup has established several resources to help manage the documentation project, including a work management board to track issues and a Confluence space dedicated to the developer manual. They have also created Slack channels to facilitate communication and collaboration among contributors.
Future Plans:
The subgroup is currently focusing on increasing visibility and awareness of the documentation project. They plan to reach out to team leads and other key contributors to gather more feedback and encourage participation.
The long-term goal is to establish a sustainable process for maintaining the developer manual, ensuring that it remains up-to-date and relevant as the project evolves.
The discussion centered on the upcoming migration to JDK 21 and how the SysOps team should be involved in the decision-making process. Given the operational impact, it was agreed that SysOps needs to play a significant role in evaluating and preparing for this change.
SysOps' Role
There was a consensus that SysOps should review the JDK 21 migration before the TC makes any decisions. This would ensure that operational concerns, particularly for stakeholders like EBSCO, are fully considered.
Scheduling and Coordination
It was decided that SysOps would first meet to discuss the JDK 21 migration and related operational issues. Following this, a TC meeting will be scheduled to incorporate SysOps’ feedback into the final decision.
Next Steps
A Wednesday meeting was planned for August 28th to review the outcomes of the SysOps discussion and further refine the OST process to ensure better coordination between SysOps and the TC.
In the Sys Ops SIG meeting the topic of Reference Data Upgrades came up. The SIG thinks that the solution of this problem for mod-inventory-storage is not enough, but that this problem needs to be solved in a general way, for all modules.
There has been a long discussion 3-4 years ago about how FOLIO should handle reference data upon upgrades. See these links for background:
The issue at hand involves the handling of reference data during system upgrades. In previous upgrades, some institutions experienced data loss where customized reference data was overwritten by default settings during the upgrade process.
This problem was particularly highlighted in recent upgrade cycles, prompting a need for a more robust solution to preserve institution-specific customizations.
Existing Solutions and Approaches
Circulation Module Example:
The circulation module had addressed this issue by implementing a solution where reference data is only installed during the initial setup and skipped in subsequent upgrades unless new data is introduced in the upgrade. This approach prevents the overwriting of existing customized data.
The TC discussed whether this solution could be standardized and applied across other modules facing similar issues.
Challenges with Current Approach:
While the circulation module's solution is effective for preserving existing data, it does not account for scenarios where the reference data schema changes in new versions (e.g., adding new fields or making structural changes). In such cases, simply skipping the installation might not be sufficient, and more complex handling might be required.
Discussion Points
Standardization Across Modules:
The TC debated whether a similar approach should be mandated across all modules to ensure consistency and prevent data loss during upgrades. However, it was noted that this might require module-specific adjustments, depending on how each module manages its reference data.
Need for a Broader Solution:
There was recognition that a broader, more flexible solution might be necessary to handle various scenarios, such as changes in reference data structures. This could involve more sophisticated checks during the upgrade process to determine whether and how data should be updated or preserved.
Potential Actions
Subgroup Formation:
The idea of forming a new subgroup to focus on developing a comprehensive strategy for reference data handling during upgrades was floated. This subgroup could explore creating an RFC (Request for Comments) to propose a standardized approach across the project.
Review of Previous Work:
It was suggested that before moving forward, the TC should review previous efforts and discussions on this topic, including past proposals and proof-of-concept work that may have stalled due to resource constraints. This review would help ensure that any new efforts build on previous work rather than starting from scratch.
Next Steps
Further Discussion:
The TC agreed to revisit this discussion in the next meeting, with members encouraged to review past work and consider whether they are interested in participating in a potential subgroup. The goal would be to establish a clear path forward for managing reference data during upgrades across all modules.
Good to know. I have had at least one team mention that they'd still like to meet one on one anyways. Perhaps I'll still need to move that direction anyways. 00:53:53 Patrick Pace: Sorry. Had my mic on. 00:56:21 Ingolf Kuss: For mod-circulation-storage, there are currently two Jira issues which are being worked on, one for the Poppy release, the other one for the Quesnelia release: https://folio-org.atlassian.net/browse/CIRCSTORE-517 https://folio-org.atlassian.net/browse/CIRCSTORE-516 01:00:12 Patrick Pace: I have to go. Thanks everyone.