2020-12-9 Meeting notes

Review and comment on this page: Transferring Performance Testing to FOLIO Teams

Discussion:

• It will be less efficient to have all teams acquire and maintain the skills needed to perform these tasks.
• We'd still require a PTF
• Using these tools to pinpoint where performance issues are is not trivial - it's complicated
• There's no clear approach for Core Functional - since this team manages modules that include contributions by others - would it be responsible or teams that created code in question?
• Note that we have not yet reached a point where teams are creating jmeter tests to be used in testing performance to very their changes haven't produces regressions. Perhaps we should start with this. Likely this hasn't happened yet because of:
  • Learning curve and inability to write/execute/understand the tests
  • Capacity is limited - so teams haven't been able to allocate time to explore this work OR they haven't planned for this effort as part of the rest of their work, even when a portion of their time (40%) should be available for things like this (bug fixing, performance, etc.)
  • Unclear whether POs have created stories to do this work
• The proposal suggests the way to integrate this capability within teams is to identify a single person to receive training/experience and communicate with PTF.
• This issue hasn't been explicitly presented to the Tech Leads, although the general concept of being involved in performance testing has been discussed.
• Might want to identify the 'dedicated' resource that the proposal suggests to be the person to write the tests that aren't getting written today

Actions:

• Read the proposal
• Ask Martin to attend and answer questions

https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=169

Craig McNally, Ryan Berger, Matt Reno and Zak Burke (and possibly others) have been part of reviewing pull requests and have been exposed to the code. The picture is not pretty - not done in the same way as other FOLIO modules, clear evidence of a ported application, small functional changes requiring 1000s of lines of code being changed.

Duplicate storage is very problematic - likely the need for local storage of MARC records is so intertwined with the current code that separating those dependencies (and using SRS for storage) is equal to rewriting it. Note that there may be some practical lessons to be learned from how MARCcat leverages local storage for dealing with Authorities and other challenges related to a cataloging system.

Conclusion, TC would not be in favor of using the current code base toward a future Cataloging App.

Further we should pull MARCcat out of the FOLIO Releases distribution (forgotten by some that it was still included).