2020-04-27 Meeting notes

 Convener can create the minutes page and set agenda but (if it's me) is lousy at taking notes

Zak_Burke will begin as minute-taker

First Assignment:  Software Support  - 

• Focus on identifying, reporting on,  prioritizing, and fixing software bugs that effect Production ( currently Rounds I and II, and ERM) instances
  • ie How does a production library report a bug and what happens once it is reported? (This might be our most cut and dry use case and therefore might be a good place to start????)
• Briefly, the charge is: determine process for production libraries to report bugs to the Folio community to get them prioritized and addressed
  • before a Jira is created in folio, it must have been triaged by the library's own support system in coordination with their Folio hosting provider (e.g. EBSCO, IndexData, Bywater, etc.)
  • only after that process is complete would a ticket be filed with Folio
• Holly Mistlebauer has published a detailed workflow diagram for this process; we may need a simplified version for external folks to quickly review

• Define Production - system used in a real life workflow (system of record, source of truth)
• Stable testing environment of the latest production release (not cleared nightly) - Could be the bugfest 
  • Anton Emelianov : bugfest may be a good env for this purpose; it will always reflect latest released  version of Folio. Eventually, we may see libraries with still older versions of Folio. Inventory data is from U of Chicago; user data is synthetic. Work is ongoing to add additional records to additional modules, e.g. requests. The one downside of this would be during actual bugfest weeks, i.e. during the quarterly releases. There are "old" and "new/current" bugfest envs; could potentially use "old" env for bug triage. Any other effort to maintain additional systems is likely cost/time prohibitive. 
  • What about needing to make config changes, e.g. circulation rules and permissions, in order to reflect an end-user's env? 
  • Must also be careful not to break data required for certain bugfest test cases. This is a potential gotcha; not immediately sure how to resolve it.
• Production Support JIRA project (thank you Anton!)
  • priority: may require further discussion.
  • assignee: assign to PO in order to verify this is a bug
  • confusion around reporter inst/impl provider/hosting provider? These may  be the same in some cases, but can be diff't e.g. if Bywater uses EBSCO hosting. Rename "Impl provider" to "Support provider". Rename "Reporter institution" be renamed to "Affected institution". 
  • Do we need a way to determine how many institutions a bug affects? Can we use "votes" to assess this? 
  • Do we need additional fields such as Browser version, OS, OS version, etc? Chrome is the only supported browser at present though we anticipate adding support for additional browsers at a later date. 
• concern that this feels like a high barrier to participating in an open source project
  
  • counterpoint: folks testing can ask so many questions that they drown slack/Jira channels; in fact we have already seen this.
  • Let the focus of this project be solely on supporting production instances
• Need a matrix of which institutions using which apps and which versions, along with their dates of implementation
• JIRA rankings to reflect SOT priorities.   Go-live, 3 months after, etc do not mean anything to a SOT library. 
• FOLIO community focus on not only developing software, but supporting SOT libraries