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 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 to the issue. This is the default state.

active (needs more info)

There is insufficient information in the issue to proceed. Should no additional information about the issue be provided, the issue may be marked either "closed" or "won't fix" at the discretion of the reviewer.

patch (code needs review) -- "CNR"

A patch has been created and needs review and testing. With sufficient positive feedback, the patch may be promoted to the status "patch (reviewed & tested by the community)" (see below for details). If a review finds a problem with the patch, it should instead be marked as "patch (code needs work)".

patch (code needs work) -- "CNW"

The patch needs additional work before it should be reviewed. The author of the patch may indicate that it is incomplete, or the patch has gone through the reviewing process and has received feedback about areas where it needs improvement.

patch (reviewed & tested by the community) -- "RTBC"

The patch has received a thorough review and test by one or more experienced developers, and they have deemed it as ready to be committed to the project.

One should not set their own patch to this status. Patches need to go through the review process. Some exceptions may be made if another developer voices their support, or when the patch is utterly trivial (e.g. fixing a spelling mistake in a comment).

At the end of the day, setting an issue to this status is a judgment call: if you have thoroughly tested and reviewed the patch and believe it is ready, you may change the status; if you are unsure, the status should not be changed. Simply add the findings of your review to the issue.

Remember that even if one or two developers believe a patch is ready, doesn't necessarily mean that it will be committed. Patches at this status may still require additional reviews to help ensure that the patch is truly ready. If it is not, the status can be reverted to an earlier status. The better the reviews, the more likely the code will actually get committed.

If a patch remains at this status for a long time, it should be reevaluated to determine if the status is appropriate.

patch (to be ported)

The patch has been committed to a branch of the project, and still needs to be committed to another, but the patch doesn't apply directly and needs to be modified to do so.

fixed

The issue has been resolved (usually by committing a patch). Issues that remain in this state without any additional comments will automatically be set to "closed" after two weeks. This gives interested parties time to reactivate the issue if they see a problem with the fix and also allows time to see that a change has been made.

duplicate

A similar issue has already been created. The duplicate issue should provide a link to the primary version of the issue.

postponed

The issue seems like a good idea, but other (often related) issues need to be dealt with first. The intention is to come back to these issues at a later date.

won't fix

It has been decided that this issue will not be fixed. This includes feature requests that are deemed to be outside the scope of the project, and bug reports that cannot be reproduced or are unsupported.

by design

The raised issue has been deemed not to be an issue. It is an intentional part of the project.

closed

The issue is no longer current. Issues that have reached this status should typically not be reopened, but instead a new issue should be opened, providing a link to the closed issue.

Closed issues do not appear in the default view of the issue queue. This provides a cleaner queue, while still maintaining the issues for historical reasons.

Please note that issues marked as "fixed" are automatically marked as closed after two weeks. You should not need to set this status yourself.