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
Support SIG Support (Tools needed for effective Support)
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.
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
get a list of support providers and their users who are authorized to add tickets to the SUP projects