Life of a Bug Report
Recently, a cultural wind of “hating on stale bot” has reached me. It made me think, what is a good way to manage software bug reports?
After 2 days of thinking, I came up with this scheme from scratch (not learning from any existing bug report management scheme). Any resemblance with existing bug tracking scheme is coincidental. Any resemblance with TCP is intentional.
Terminology Used
Issue: a bug report
Reporter: whoever cares to diagnose the problem. this could be who filed the issue, or someone who found the same problem but did not create the issue
Maintainer: whoever will handle/is working on/solved the issue.
The four discrete states an issue can be in are shown in the format
STATE-NAME: its condition to be met
Tale of an issue who lived an uneventful life
Here is an issue that passed through all four stages/states in our scheme.
issue opened
SYN-RECEIVED: reporter has the will to cooperate in diagnosing the problem (sometimes they just disappear)
ESTABLISHED: maintainer and reporter has reached an understanding of the problem
CLOSE-WAIT: maintainer think they have fixed the bug
CLOSED: reporter confirmed the fix
issue closed
How to use this scheme
Create one tag for each of the four states.
Apply a tag when, and only when its condition is met. Sometimes you need to remove the ESTABLISHED
tag because the maintainer has not understood the problem at hand.
The four states are strictly monotonic, so an issue can be tagged with both SYN-RECEIVED
and ESTABLISHED
, or just ESTABLISHED
(if your bug tracker only supports one active state).
You may also need tags like wont-fix
. You are expected to modify this scheme to make it work for your project.
That’s it.
For more information, please re-read.
Why does it work
personal connection something something
I am not going to convince you to use my scheme. Use it or not.