Versions Compared

Old Version 2

changes.mady.by.user Danno Ferrin

Saved on

compared with

New Version Current

changes.mady.by.user Sally MacFarlane

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info

For information on our defect prioritization policy, check out this page

Note
titleProcess under review

This is a proposal for our bug triage process and hasn't been finalized. Please share your thoughts with us!

What is Bug Triaging?

In Besu we have a well-defined policy regarding bug categorization. We categorize bugs based on their Probability (how often) and their Severity (how bad). Using these two scales, we end up with a final priority for the bug, that defines how important the bug is.

In a nutshell, our bugs are categorized into 5 priorities. If you want more details about the categories head to our policy page. These buckets are:

PriorityExamples
Very High (P1)
  • Security issues
  • Non-planned backward incompatibilities, preventing the node from participating in the network
High (P2)
  • Degrading performance issues
  • Unexpected behaviour of core features (DevP2P, syncing, etc)
Medium (P3)
  • JSON-RPC request not working with a specific client library due to some loose spec assumption
Low (P4)
  • Node doesn't start up when the configuration file has unexpected "end-of-line" character
Very Low (P5)
  • JSON-RPC json object response not ignoring keys with null value
  • Typo on a CLI command description

Why is it important?

Every All software has bugs. And sometimes we don't find them. This is something that we need to live with. However, when we do find bugs . We we need to do our best to identify the potential impact of that bug in our system.

...

  1. Identify that a bug doesn't have a priority (no Px label)
  2. Use the bug categorization policy to determine the final priority of the bug
  3. Based on your assessment, add the corresponding label to the bug
  4. (optional) Add a comment to the issue explaining the rationale (justifying the severity and frequency analysisprobability analysis)

Here is an example screenshot of how we can spot bugs that have been prioritized (or the ones that still require an assessment):

...

We try to be deterministic on our assessments, and most of the time it will involve some discussion. However, if you feel like the assessment on a bug priority is wrong, you can always add a comment on the issue and start a discussion. There is also the option of starting a conversation on Rocket Chat Discord.

Can I change the priority of a bug?

...

What if I don't have enough knowledge of a specific area to prioritize a bug?

That's ok! The more Deeper understanding of the impact of a bug will come from the people that work closer to the affected area of the code. Leave it to them!