-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define process for categorizing bugs into H, M, L severity #588
Comments
The SoW here as I see it is just:
Acceptance criteria
|
The table above is useful for defining our strategy - its about how likely a bug is to occur as well as its severity and the product determines where it is sensible for us to expend resources to protect the product. However, for bugs that have actually already occurred the likelihood is nullified. Therefore, for the purposes of bug triage, we can use the severity column only. We evaluate a bug against the criteria in Column 1 and assign it a L, M or H tag depending on the severity score. Severity 1 = L The latest the labelling will be done is the next available bug triage call, which is now scheduled for 1600 UTC+1 on every Tuesday. Adding this to the contribution guideline documentation and any further discussion can happen there. |
Proposed this assessment rubric in #663:
The mapping of severity to label is as follows:
|
Sub of #651
What
Create a process with a rubric for categorizing bugs into low, medium, high categories to support bug triage.
Why
As a core developer I want to have a clear decision making rubric for categorising bugs. This will allow us to make better decisions about how bugs should be handled, faster, and provide more transparency to users.
Context
We want to apply a consistent bug assessment process in our bug triage calls. This requires us to discuss and agree a decision making rubric and then make it public via our
if
github repository. Ideally we also have a set of appropriate remediations for bugs in each category.The following table shows a draft risk matrix for the various deficiencies that could be reported for IF. The likelihood and severity of each bug is scored out of five and their product is the overall risk score, with a maximum of 25. This could form the basis of a bug categorization process.
Prerequisites/resources
Bug reporting template should be updated( issue here)
Statement of Work
Acceptance criteria
The text was updated successfully, but these errors were encountered: