/
DRAFT - Existing Module Technical Evaluations

DRAFT - Existing Module Technical Evaluations

Overview

This page defines the TC's process for evaluating already-released FOLIO modules against current technical criteria. It is not release-gating; it is an improvement and visibility process that gives TC and module owners a shared baseline for tracking technical gaps over time. The process is expected to evolve with experience.

Guiding Principles

  • Existing module evaluation is for improvement, support, and visibility into technical gaps, not for removing modules from releases. Participation remains best effort.

  • Findings should use improvement-oriented language such as "meets criteria" and "needs improvement" rather than describing a module as having "failed."

  • Teams and Product Owners decide what remediation work happens and when. TC tracks progress with professional courtesy rather than enforcement.

  • Existing modules should be evaluated against the TC technical criteria as the baseline, with room for case-by-case adjustments when TC agrees they are warranted.

  • The default is to document criteria gaps rather than grandfather them away, unless TC decides a specific exception is warranted.

Queue and Cadence

  • The queue is the prioritized list of evaluation Sub-tasks in https://folio-org.atlassian.net/browse/TCR (component Existing Module Evaluation). TC co-chairs own the queue and its ordering; parent Tasks act as persistent module anchors and are not themselves the queue. Sub-tasks are created when a cycle is next up, not pre-created for every module.

  • The current target is to shoot for about 10 reviews per year, while recognizing that actual throughput will depend on reviewer logistics and capacity. The provisional SLA for a single evaluation is 3 weeks.

  • Sub-task order should prioritize core or high-impact modules first. The current direction is to work application by application, starting with https://github.com/folio-org/app-platform-minimal , and TC will set the next application focus when that area completes. Re-evaluation is a mix of on-demand (specific concern, major version, new or changed criterion) and queue-driven (the module coming back up in the ordering). A new Sub-task under the persistent parent Task is what opens a new cycle; there is no fixed annual schedule.

  • TC may use additional community reviewers to increase capacity, provided conflicts of interest and review logistics are handled appropriately.

Process Summary

  1. Keep the https://folio-org.atlassian.net/browse/TCR queue prioritized and current so teams can see what is coming.

  2. Assign a reviewer, create the module's persistent Task in TCR if it does not already exist (component: Existing Module Evaluation), open an evaluation Sub-task for this cycle, and notify the Product Owner at least 3 weeks before the review begins.

  3. Evaluate the module against the current TC criteria and commit an evaluation writeup to https://github.com/folio-org/tech-council/tree/master/module_evaluations showing where it meets criteria and where it needs improvement. Link the writeup from the evaluation Sub-task.

  4. Review the findings with the team, then create or link Jira follow-up work as needed.

  5. Close the Sub-task once the evaluation writeup is merged and follow-up work is tracked.

Criteria, Tracking, and Follow-up

  • Existing module evaluations should use the TC module criteria as the baseline. Case-by-case adjustments are possible when TC agrees, but the default is to document gaps rather than grandfather them away.

  • Use the existing https://folio-org.atlassian.net/browse/TCR Jira project with a component called Existing Module Evaluation to separate this work from new-module submissions.

  • Each module gets one persistent Task in TCR that lives indefinitely and accumulates evaluation history. Each evaluation cycle is a Sub-task under that Task; the Sub-task tracks lifecycle status and links to the writeup in folio-org/tech-council/module_evaluations, which is the source of truth for findings. Remediation work is linked from the responsible team's own project. This uses only the existing TCR issue types — no new types or workflow changes are required.

  • The result of an evaluation cycle is a merged evaluation writeup plus linked follow-up work, not a release decision.

  • If a team cannot prioritize finding right away, that is handled with professional courtesy.. A long backlog is not itself a concern. If outreach is not productive, TC can share that with the Product Council for visibility and proceed using publicly available information so the cycle is not blocked.

  • TC should periodically report aggregate process value, such as how many modules were reviewed and what kinds of issues were discovered and addressed.