Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
Existing Module Evaluations
ALL
Open Questions
Consequences & Remediation
What should it mean, in practice, when an existing module "fails" an evaluation?
There is no threat of removal from releases at this time; participation is best effort
and the focus is improvement.
Is “fails” the correct term to use? The focus is really on improvement.
“fails” might be intended to be interpreted as an objective success/fail technical term; however, there is a desire to avoid using “good”/”bad” terminology.
Using “fails” might not be helpful, especially considering the modules are in production.
What about “meets requirements” / 'does not meet requirements” or some other word than “requirements”.
Possible words: “Criteria”? “Needs Improvements”?
How should feedback from an existing module evaluation be prioritized, and who decides what remediation work happens?
The team should be able to perform their own prioritizations and apply their own judgements.
A related question: “How should the feedback be given”? Such as an e-mail? A Jira? There might be preferred ways that are different between different teams.
We should be able to trust the teams to make these decisions themselves.
We can just provide the information we have at the time rather than follow some specific process.
Consider instead prioritization from the perspective of doing the evaluation rather than the teams priorities.
The longer production code exists under not a given standard, the more it becomes legacy code. This typically makes teams nervous about breaking functionality and being afraid to make any changes at all.
Jira may be a good place for these kinds of things. Anybody can create Jira tickets and the teams or POs can close or manage Jira tickets as they see fit.
The discussion has led to use deciding to use Jira to provide the feedback. There should be a label to help track this information. Alternatively, there could be an EPIC created. We aren’t describing the specific details yet. We just want this in Jira, somehow.
Is there consensus or buy-in from people managing development on how evaluation feedback should be handled?
We do not control resources. Most likely the Product Owners will handle this. We lack the power to stop anything if, say test coverage, no longer meets the minimum requirements.
What are our powers, people power or soft-power, that we can utilize to resolve evaluation concerns?
We can reach out, describe the problem, and ask if there is anything we can do to help them resolve the problem. This kind of outreach is often well received. It is probably friendlier to reach out outside of meetings and address concerns or problems.
Focus the interaction on offering help rather than providing problem complaints. Talk about how meeting these criteria can improve the module. Try to increase confidence. Treat these concerns or problems as opportunities to improve.
We can use CSPs as a nuetral ground for bringing in improvements once made.
Don’t force some deadline, but talk with the teams or POs to try and establish a game plan on helping them resolve the concerns or problems.
What should happen if a team does not prioritize or act on evaluation findings?
The TC tracks progress with professional courtesy but has no enforcement mechanisms at this time.
Tracking but not enforcing is a good approach. Look at it from a wholistic point of view rather than an individual point of view.
It can be packed for some time and then revisited later.
Should there be a controlling Jira issue to associate the existing reviews?
There should not be a new Jira Project for these issues.
We can revisit these Jira issues, periodically. No new status is needed for every project.
There could be some time frame, such as 9-months. We can also provide statistics on this time period in such a way that it becomes less personal.
We have concluded that if the PO says “no”, then we should take it to the CC because at that point it is not a TC issue.
A long priority, such as 3 years, is not a “no”.
How should the process handle architectural issues or anti-patterns that teams cannot realistically re-architect right away?
Some criteria may be adjusted or grandfathered for existing modules depending on their age
and circumstances.
Some agreements.
There is some discomfort on this. Criteria should not be adjusted. We can use these situations to reference Jira issues during future discussions and debates.
This can become more complicated when TC deprecates something. If we create provisions for older modules, then we are effectively grandfathering in some way.
We are out of time and stopped here. New notes 4/1/2026
@Jenn Colt if PII disclosure is not included for a module, is that work that we would request be done as part of an existing module evaluation? Note that this is duplicative work that is also being undertaken by the Privacy SIG
@Maccabee Levine notes this is a development task because there’s code review involved
@Tod Olson notes that this is increasingly important to implementing institutions
@Ingolf Kuss asks if this is really an issue and if it is being monitored automatically
Consensus: advance this in the Privacy SIG in terms of monitoring compliance. Eventually add to the module evaluation checklist. @Tod Olson will look at bringing this to Product Council to establish the priority. Technical Council would oversee implementation.
Pace & Scope
How many modules per year should be evaluated, and what load does this place on TC reviewers and teams?
Load is the same or higher than new module evaluation
@Maccabee Levine 1 per PC member per year (11 per year)
@Jenn Colt maybe 1 per month with December and July off (10 per year)
@Ingolf Kuss maybe 1 every 3 weeks (10 per year)
@Olamide Kolawole constant module evaluation may not be realistic. Maybe 5 per year as a good starting point, with possibility of adding more as tooling improves.
@Olamide Kolawole Evaluation may not need to be performed by TC members directly – e.g. could recruit within our institutions to be able to increase our capacity.
@Shelley Doljack how would that work in terms of granting access to the repo, etc.? Some logistics would need to be worked out. Also need to be aware of potential conflicts of interest.
@Julian Ladisch there should be a queue to draw from and just move from one to the next.
Consensus: We will have a prioritized queue of module reviews. We will shoot for 10 per year. We will pull in other community members to help with reviews.
Should core or high-impact modules be prioritized first?
Consensus: Yes
What are the selection criteria for choosing modules to evaluate, and where should they be documented?
- Age: modules from around rows 220-270 in the release spreadsheet (neither too old nor too new)
https://docs.google.com/spreadsheets/d/1_GGccpX4E0UBs1xZbCkxj24BopsUN_uUo9JCPEm8suQ/edit
- Type balance: both frontend and backend modules
- Quality metrics: tools like SonarCloud (https://sonarcloud.io/organizations/folio-org/projects)
and Semgrep (https://semgrep.dev/orgs/semgrep_folio_org/supply-chain/dependencies) to identify
modules with room for improvement
- Likelihood of success: preferably modules where discovered problems can realistically be resolved
@Olamide Kolawole do we need to have formal criteria or just declare what is “core” or “high-impact”
@Maccabee Levine the order probably doesn’t matter (@Jenn Colt concurs)
@Shelley Doljack look at application descriptors – look at app-platform-minimal first
Consensus: Go application by application. Start with app-platform-minimal, go to inventory, orders, ERM.
Communication & Value
How do we ensure the process adds concrete value and is not just an academic exercise?
Defined success metrics: teams feel supported rather than criticized, issues identified are
actionable and get addressed, the process is sustainable and not overly burdensome, community
accepts and values the process, and code quality across FOLIO improves over time.
@Olamide Kolawole Value in terms of security issues, test coverage, etc. seems self-evident
@Maccabee Levine regular communication of metrics (number of modules, issues that were resolved, etc.)
@Olamide Kolawole where do we highlight this?
Should the process include documenting where existing modules currently fail as a baseline record(so that a “before” image is captured), and should value be judged by how teams act on findings?
@Olamide Kolawole change language around “fail”? Need to document when the module doesn’t meet criteria.
Consensus: Document where module “needs improvement”
How should the scope, pace, and timeline be communicated to the community, including how far in advance teams know their module is coming up for review?
@Olamide Kolawole if we build a queue then we know what is coming
@Olamide Kolawole how do we communicate to the team that this is coming?
@Shelley Doljack Slack communication that references a (new) Confluence page that shows the queue
@Wayne Schneider work directly with PO, use Jira TCR project for on-going communication
@Ingolf Kuss need to communicate with PO at least 3 weeks prior to undertaking evaluation
NA
Zoom Chat
2026-04-01 10:04:56 From Wayne Schneider To Everyone: I missed my turn so could scribe if needed
2026-04-01 10:24:27 From Jenn Colt To Everyone: I can scream loud! Tod Olson:😀
2026-04-01 10:24:58 From Julian Ladisch To Everyone: I can't hear you ;-) Jenn Colt:😂
2026-04-01 10:37:34 From Jenn Colt To Everyone: I’ll change my answer to 5
2026-04-01 10:37:49 From Gerhard, Jeffery To Everyone: I like the vague 5 to 10 Jenn Colt:👍
2026-04-01 10:39:20 From Tod Olson To Everyone: I like Julian's idea about having a queue of module reviews that the TC works on. I suspect that 5 to 10 reviews of older modules is what could be accomplished in a year.
2026-04-01 10:39:27 From Shelley Doljack To Everyone: Oh, they could fork and open a PR.
2026-04-01 10:50:54 From Tod Olson To Everyone: I need to drop off. Thank you all for the productive discussion!
2026-04-01 10:53:15 From Shelley Doljack To Everyone: “Needs improvement” 😁 Jenn Colt:👍
2026-04-01 11:00:22 From Maccabee Levine To Everyone: Sorry have to run to next meeting