Page tree
Skip to end of metadata
Go to start of metadata

Goals

The Support SIG works with libraries, Product owners and Developers to surface bugs effecting libraries that are, or will soon be, in production with the intent of:

  • assuring system functionality
  • surfacing issues that will effect future FOLIO development
  • facilitating prioritization and resolution of P1-P3 level bugs in order that they be released in hotfixes
  • improving specifications
  • improving FOLIO


Definitions

  • Bug:
    • Specified functionality does not work as defined in User Story by Product Owner
    • Spec Bug:  Functionality does not work as assumed, but developers have delivered what the Product Owner defined in the User Story. The RCA (root cause analysis) designation of these bugs is "Incomplete requirements"


Support Process for when a bug is created by in the Support project

  1. Bug is created in JIRA using the Support Project
  2. Support SIG reviews the Bug, gathers additional details if needed
  3. Assigns bug to appropriate Dev team
  4. PO for the Dev team moves the Jira into the appropriate project
  5. PO adds the "Support' label if it does not already exist


Support Process for when a PO or Developer identifies a bug effecting a Production library ....

  1. PO, or Developer creates a bug in JIRA
  2. Using the Team Vs Module Matrix assign the appropriate Dev Team (to the best of your understanding)
  3. Add the "Support' label
  4. Add the Affected institution - section of Jira
  5. If the issue is urgent the reporter should
    1. tag the relevant PO in the issue comments.  If user is unable to determine the correct PO, then tag the FOLIO Lead PO
    2. Assign a "PI" priority - which notifies the Support SIG
  6. If applicable assign the RCA


Support Process for when a PO or Developer identifies a bug JIRA as a duplicate UXPROD

If a PO wants to close a bug as a duplicate of a UXPROD features they will add the "support" label to the existing JIRA and  for each institution that is impacted add them to the: Affected institution - section of Jira.

  1. If the issue is urgent the reporter should
    1. Assign a "PI" priority - which notifies the Support SIG


  • No labels

1 Comment


  1. Thanks for writing this up, Kelly Drake.   Does this process make sense to you? 


    1. Implementers file a bug when a feature not working as expected
    2. PO reviews the bug and if:
      1. Feature is not working according to the original development specification - Bug will retain issue type = bug and will be prioritized for development in the bug fixing capacity allocated for each team
      2. Feature is not working but expected behavior was never specified or was specified differently - PO will convert the bug to:
        1. Story - For small changes.  If the story is considered critical, PO can prioritize it as part of the bug fixing capacity allocated for the team.  Criticality is indicated by "Customer priority" and the number of "Affected institutions" (both fields on the JIRA issue).
        2. UXPROD features - For large changes that require advanced planning.  

    NOTE: Sometimes a story or UXPROD feature will already exist in the backlog.  In these cases, the PO may close the bug as a duplicate of the existing issue.  They will apply the "support" label to the surviving issue so it can be tracked as an issue needed by production libraries.