Status levels of Issues
Each issue has a status assigned so that we can tell at a glance what progress has been made with each issue. These can then be sorted to refine what type of issue you want to deal with (for example, if a developer is in the mood to review some patches they can search for only those issues). The issues are also color coded in the queue based on issue status.
Simple definitions
Active
No patch is attached. This is the default state.
Active (needs more info)
Somebody requests more info from the creator of the issue. Should no response be forthcoming, the issue may well be marked "won't fix".
Patch Needs Review (PNR)
Patch may or may not be commit ready, but the developer needs some active feedback. The nature of that feedback will depend on the state of the patch, but it may be to test for bugs, or features or even concept. With enough positive reviews, the patch can be marked RTBC (see below). If a review finds something wrong with the patch, it will instead be marked as 'needs work'.
For more details on reviewing patches see this page.
Patch Needs Work (PNW)
Either the author of the patch knows the patch is not fully ready yet, or the patch has gone through the reviewing process and has received feedback about areas of improvement.
Patch Ready To Be Committed (RTBC)
Patch has received a thorough review from one or more experienced developers, and is deemed ready to be committed into the project.
Anyone can change the status to RTBC, but care should be taken when doing so as this sets expectations as to the quality and readiness of the patch -- set it too early and you could waste core committers time. One should usually not RTBC his own patch, unless someone else voices their support, or when the patch is utterly trivial (e.g. fixing a spelling mistake in a comment). For a more complicated patch - one that makes a change to the logic of the code - more reviews are usually desirable before changing the status to RTBC. At the end of the day, it is a judgement call: if you think it is ready change the status; if you are not sure leave it alone and just write your review.
It should be noted that just because one or two developers believe it is RTBC, doesn't necessarily mean it is. This is still a good stage to add more reviews to help make sure the patch truly is ready. If it is not, the status can be altered back to an earlier status. The better the reviews, the more likely the code will actually get committed.
After some time at this status the patch should be reviewed again to see if it is in the right queue.
Patch (to be ported)
The patch works in one version of the project, but needs to be ported to work in other releases.
Fixed
The issue has been resolved (usually by applying the patch).
Duplicate
This issue has already been created elsewhere. The duplicate gets marked as such, and a link points to the primary version of the issue.
Postponed
The raised issue seems like a good idea, but other things need to be done first. When marked postponed, the intention is to come back to it at a later date.
Won't fix
For whatever reason, the maintainer has decided that this issue should not get fixed. For example, a feature request may be deemed as outside the scope of the project. Or a bug report may be for something that the maintainer does not wish to spend time supporting.
By design
The raised issue is not deemed an issue by the project maintainer, but is instead an intentional part of their project.
Closed
When an issue is marked as 'fixed', it stays viewable in the default issue queue view for two weeks. This gives interested parties time to activate the issue again if they see a problem with the fix and also time to see that a change has been made. After two weeks, the issue is automatically marked as closed so that it disappears from the default view in the issue queue. This provides a cleaner queue, while still maintaining the issues for historical reasons. You should not need to set this status yourself.