What I am thinking about here are the various stages, not states. So I am not worried about open/closed states since that is obvious. I am thinking of the more fine-grained stages an issue goes through.
Step one is even getting an initial report. It could be from a total stranger, so nothing really should be assumed about the issue. Basically the issue is "new".
With the bug report filed, now you need to "verify [the] bug". This will help get rid of duplicates or things that are out of date because they no longer affect Python.
With the bug verified, a "test [is] needed". You can't really work on a bug without having a test to work against.
With the bug verified and a test to reproduce it, now it "needs [a] patch". Already having a test should help make getting a patch a little easier since you have something to work against.
Once there is a patch from some kind, patient soul, there is a need for a "patch review". A committer need to verify that the code meets our standards, it actually fixes the bug, etc.
But sometimes even a committer needs another committer's opinion, that can lead to a "commit review". We are actually doing this for the release candidates; all commits need a review from another committer (sans docs) before the code can be committed.
After that, the code should be "committed" or "fixed". Obviously there are other possible stages/results, such as "duplicate", "won't fix", "invalid", "out of date" (which could also just be considered "invalid"), or "works for me" (which could also be flagged as "invalid"). But those seem to be the typical steps an issue goes through from being reported to getting fixed:
- verify bug
- needs test / test needed
- needs patch /patch needed
- patch review
- commit review
- committed / accepted / fixed