Last updated April 5, 2015.
- No patch is attached to the issue. This is the default state of a new issue, but may also sometimes be used for 'resetting' an issue that has gotten off-course even if the issue has old patches attached.
- Needs Work ["CNW"]
- There is a patch attached to the issue, but 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.
- Needs Review ["CNR"]
- A patch has been created and needs review and testing. The Testing Bot uses this status to trigger an automated review of the patch, and reports the results. Patch Reviewers also use this status to find patches that need to be reviewed and evaluated. With sufficient positive feedback, the patch may be promoted to the status "Reviewed & Tested by the Community" [see next definition]. If a reviewer, either human or Bot, finds a problem with the patch, it will then be marked as "Needs Work". Note that if a patch is not required in order to complete the idea described in the issue, then it is the idea itself that needs review.
- 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 one's 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, that 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, it 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.
If a patch is not needed to complete the idea described in the issue, then it is the idea that has been reviewed and tested.
- Patch (to be ported)
- The patch has been successfully committed to a branch of the project, and still needs to be committed to another, but the current patch doesn't apply to the target branch and needs to be modified in order to do so.
- 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 (fixed)" 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.
- May mean either 1) that the issue is valid and should be fixed, but other related issues (blockers) need to be dealt with first, or 2) that the issue is removed from current active work but the intent remains to return to it. In the first case, please tag the issue "blocked" and say what issue(s) it's blocked on in a comment.
- Postponed (maintainer 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 (cannot reproduce)" or "closed (won't fix)" at the discretion of the reviewer.
- Closed (duplicate)
- An identical, or strikingly similar issue has already been created. The issue being marked as a duplicate issue should provide a link back to the earlier version of the issue.
- Closed (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, issues from unsupported releases, bug reports that are too far-reaching to fix, support requests from belligerent users, etc.
- Closed (works as designed)
- The reported issue has been deemed not to be an issue. The reported behavior is either an intentional part of the project, or the issue is caused by customizations manually applied by the user (wrong configuration, code alterations, theme override functions).
- Closed (cannot reproduce)
- If no-one is able to reproduce the problem being reported, an issue can be closed with this status. It's possible that the original reporter is confused and "works as designed" might be more accurate, but there's not enough evidence to be sure. If someone else can come along and reproduce the problem, they can provide the information and move it back to "active". However, if the maintainer says the issue is "Closed (works as designed)", there's no point trying to provide further information or to reopen the issue.
- Closed (fixed)
- This status is used exclusively by the Project issue tracking system to close "fixed" automatically after two weeks of inactivity. You should not need to set this status yourself. 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.
NOTE: An overview of all the drop-down menus on the "Submit issue" form can be found on the Issue Submission Form Description page.