What are the typical steps an issue goes through?

During the rather complicated beta period for Python (having two major releases being released at the same time is a lot of work!), it has become apparent our issue triage workflow could use some TLC. I have always planned on leading the charge to clean this up ever since we moved over to Roundup for our issue tracking. And having read Django's triage guidelines, I really have wanted to fix our workflow.

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:

1. new
2. verify bug
3. needs test / test needed
   
4. needs patch /patch needed
5. patch review
6. commit review
7. committed / accepted / fixed

What do people think of those steps? Make sense? Did I miss one? Is something a little bit too much? My hope is that when this topic is seriously visited by the deveopers after 2.6 and 3.0 final are released we can end up with a workflow that lets people jump in where they feel comfortable. So if you don't feel up for writing patches, but think you can write a unit test, then you can easily find those issues that need a test. Or if you don't feel up for anything beyond verifying a bug report is legit, then you can do that to. My thinking is that the granularity needs to be there such that people can contribute at any level easily.