Issue Status field

This page describes the standard definitions of the options available for the Status field on Drupal project issues, which mostly apply to projects that are associated with software (Drupal core, contributed modules, contributed themes, etc.). Non-software projects and working groups may use the Status field in a different way.

Active

No patch or merge request 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 ("NW")

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 ("NR")

A policy, patch, or merge request has been created and needs peer review and testing. The automated testing infrastructure 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 change has gone through the review process and is considered ready for commit by one or more community members. One should not set one's own patch or merge request to this status unless another reviewer voices their support, or unless the change is trivial (e.g. fixing a spelling mistake in a comment).
 

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 community members believe an issue is ready, that doesn't necessarily mean that it will be committed. 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.

Patch (to be ported) ("PTBP")

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.

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 (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.

Postponed

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. In either case, add an item to the remaining tasks in the issue summary, typically something like "Postponed on [#1234567]".

Postponed (maintainer needs more info) ("PMNMI")

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 have the earlier version of the issue added to the "Related issues" field.

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 (outdated)

This status is used for outstanding issues filed against unsupported versions of a project. For example, when a major version of Drupal core reaches its end-of-life (EOL), this status will be automatically set on all remaining open issues for that branch.

Closed (fixed)

This status is used exclusively by the Project issue tracking system to close "Fixed" issues 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.