Defect Priority Definition for Eureka Issues
DRAFT!
Priority | When | System Impact | Business Impact |
|---|---|---|---|
P1- urgent | Must be fixed right away or in the next build. Everything else can wait. Environment provisioning is broken | Affected components: Sidecar, KONG, KeyCloak, MTE, MGR, For production: Performance issues Examples: module start, entitlement , tenant creation/deletion | TBD (An issue causing FOLIO as a whole, or a core function of FOLIO, to be unusable) |
P2 - high | Should be fixed as early as possible, preferable plan to upcoming sprint. There is a temporarily acceptable reasonable short-term workaround | Affected components: Sidecar, KONG, KeyCloak, MTE, MGR, For snapshot: Performance issues Examples: karate/cypress tests, | TBD (Known workaround is forcing the customer into unplanned spending of additional resources.) |
P3 - medium | May be fixed in current release If found in production, the fix can wait until the next scheduled release | The product or application doesn’t meet certain criteria or still exhibits some unnatural behavior while affecting one isolated piece of functionality. Possible improvements and enhancements An issue is self-contained and has an acceptable & easily reproducible workaround. Examples: | An issue causes minor impact on productivity. |
P4 - low | Fixing can be deferred until all other priority defects are fixed If found in production, the fix can wait until the next scheduled release | An issue causing almost no impact to the functionality, but is still a valid defect that should be corrected | An issue has minimal impact on normal operations. |
P5 - cosmetic | Fixing can be deferred indefinitely |
|
|