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.