1 min

Scribe

@Kevin Day followed by @Shelley Doljack

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.

Pace & Scope

• How many modules per year should be evaluated, and what load does this place on TC reviewers and teams?

• Should core or high-impact modules be prioritized first?

• 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

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.

• 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?

• 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?

NA

Zoom Chat

mike 10:04 AM
Charlotte sent me an invitation to this meeting, but I don’t understand why. Is someone expecting me here?

Shelley Doljack 10:34 AM
https://www.reddit.com/r/ProgrammerHumor/comments/9xat04/the_ancient_code/