🏡 Return back to the handbook home page
⛰️ Why are we here?
💥 How we’re building the team
💪 How we’ll support you?
⭐ Benefits
📗 Policies
💳 Expenses
🏖️ Vacations
🛠️ Engineering at Junction
📞 On call
Throughout our work, at Vital you will experience several issues that will arise from releases, products, and codes. This document is intended to give you guidance on how we think about prioritising issues and triaging them.
Bug Priority vs Bug Severity
We will have three scales - P0, P1, P2
Resolution: < 1 day
We should stop working on the cycle to fix the bug. This is reserved for serious issues that are high severity and high priority.
Examples
Resolution: ~ 2/3 days
This is likely affecting a customer but is narrowed to
Examples
Resolution: ~ 5 days
Represent pretty much anything that will only be fixed when our development team has cleared all
Examples
| Type of Bug | P0 | P1 | P2 |
|---|---|---|---|
| General | Broken feature with no workaround or any data-loss | It's a broken feature with an unacceptably complex workaround. | Broken feature with a workaround. |
| Performance Response time (API/Web/Git) | Above 10,0000ms to timing out | Between 4,000ms and 10,000ms | Between 1,000ms and 2,000ms |
| UX | “I can’t figure this out.” Users are blocked and/or likely to make risky errors due to poor usability and are likely to ask for support. | “I can figure out why this is happening, but it’s really painful to solve.” Users are significantly delayed by the available workaround. | “This still works, but I have to make small changes to my process.” Users are self-sufficient in completing the task with the workaround but may be somewhat delayed. |
| Vulnerability | Any PII or PHI is at risk of being leaked. | ||
| Tests | Live production tests are broken. | ||
| Provider | Provider outage is widespread across all customers. Or all customers are missing summary data types. |
<aside> 🚧
under construction
</aside>