Issue queue triage intro and comment templates

Before you start: Review How to give constructive feedback.

Triage flowchart

What is issue triage?

Issue triage is when you review open issues (often ones marked as "Active") to see if they are relevant. There are many reasons an issue may not be relevant and can be closed. It may be outdated, irreproducible, a duplicate, or work as expected. In some cases, even though an issue is valid, it may not be fixed intentionally. See more information below for closed statuses used during triage.

When triaging, if the issue is relevant and not a security issue, you can also improve the issue by:

• clarifying the issue title and/or summary
• adding or enhancing the steps to reproduce
• changing the issue category, priority, status, and/or component, if not correct
• adding or updating issue tags (including adding the "Bug Smash Initiative" tag)
• unassigning the issue if it was accidentally left assigned
• changing to the latest relevant version

Relevant contributor task: Triage an issue report

Security issues

When triaging issues, it's very important to identify any issues that should be sent to the security team. If an issue mentions anything about information disclosure, access bypass, issues with permissions, or similar security-related problems, it should be reported privately to the security team.

First, add a note in the #security-team Slack channel that you have an issue to report, but do not include which issue it is. Someone in the channel will send you a direct message (DM) for further information. Then, the security team will unpublish the issue, create a private issue, and start the process of determining whether it should be handled in public or private.

Committed but re-opened issues

Bugsmash has found that issues that are re-open have a tendency to linger and become stale. In general, it is a good idea to close the committed issue and create a follow-up for the remaining work.

When triaging these issues, first find the comment where the commit was made. The following comments should explain why the issue was re-opened. Here are some of the common ones and what action to take.

• Commit was reverted - Nothing special to do, continue with the triage.
• Left open by mistake - Change the version of the issue to the version of the commit and set the status to 'Fixed'.
• Re-opened for follow-up work - This may be adding tests or documentation etc. Create an issue for the follow-up work. Make sure to add the original issue as a related issue and to link back to it new Issue summary. As with any issue, the new issue summary should clearly explain what needs to be done so that that anyone working on it doesn't need to read the entire original issue to figure out what to do.

Comment template for Bugs that was committed and re-opened open and can be closed.

Closing stale issues

A stale issue is one that has not had any discussion or work in several years. The issue must still be triaged.

If the stale issue meets these three criteria, it should be closed:

1. The report consists only of an error or description of an error with no steps to reproduce.
2. Someone replied asking for steps to reproduce > 6 months ago.
3. No steps to reproduce were provided and/or it is only reproducible in the reporter's site.

Preferred statuses for closing issues, in order of preference:

1. Closed (duplicate) with a link to the issue that resolved it, if it's reproducible in the codebase as of when the issue was filed, but is no longer reproducible on current versions. (Use git bisect, git log -S, and/or an issue queue search to try to locate the issue that fixed it.)
2. Closed (cannot reproduce) if the issue can't be reproduced by the triager using the codebase as of the date when it was filed.
3. Closed (works as designed) if the current behavior was a deliberate design choice. **Generally, the triager should propose this status, but not set it until it's validated by a relevant maintainer/stakeholder.
4. Closed (won't fix) if a maintainer in a relevant role has made a decision not to fix an issue. Note: This status change can be perceived as harsh; be sure to thank the contributor, give specific reasons/references, and often have a peer review on the status change from another maintainer (e.g., for a Migrate issue, "Thanks for this proposal. I discussed the issue with quietone and heddn, and we agreed that [...]")
5. Closed (outdated) for issues that don't fall in any of the above categories, but for whatever reason are no longer relevant (especially as relates to branch end-of-life, or in cases where Drupal has changed so much in [x, y, z] specific ways that there's nothing to mark it as a duplicate of, etc.).

Templates

• Bugs that have legitimately been resolved by an identifiable issue since the reporter filed it
• Bugs that are duplicates of an existing issue that isn't yet resolved:
• Bugs that are Postponed (maintainer needs more info) where no additional information has been provided on how to reproduce the issue, no identifiable duplicate resolved the issue, AND the triager ALSO could not reproduce the issue after a year
• Bugs that are no longer relevant to Drupal 8/9 (only reproducible on Drupal 7):
• Bugs that was committed an open and can be closed:

Bugs that have legitimately been resolved by an identifiable issue since the reporter filed it:

Relevant contributor task: Identify duplicate issues

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

Or, if the contributor(s) did something more than file an issue report, thank them for that specifically, e.g.:

Thank you for reporting this issue and [providing a patch/screenshot/steps to reproduce/etc.] [Why the extra thing they did was helpful.]

As part of the Bug Smash Initiative, we are triaging issues to try and identify duplicate issue reports.

This issue was reported in [month and year]. I was able to reproduce this issue by testing Drupal core as of when this issue was filed, with the following steps:

1. Install Drupal core 8.N.x [where N is old and was the prod release as of when they filed the bug, or was the version they chose originally] with the [Standard] profile. [Or: Check out a commit from around the date the issue was filed, with git checkout [hash]].
2. [Enabling modules, etc., other steps]

When I follow the same steps on Drupal [8.9.x/9.0.x/9.1.x], the issue no longer occurs. I searched for how it was resolved using [the issue queue/git bisect/git log -S] and it appears to have been resolved in this previous issue [#1234567] So, I am closing this as a duplicate of [#1234567]. [Note: Add it to the related issues]

If this issue is different from or not completely solved by [#1234567], expand the issue summary and steps to reproduce to document the remaining issues not covered by that previous fix, and set the issue back to "Active" [or "Needs Work" if the issue has a patch, etc.].

Bugs that are duplicates of an existing issue that isn't yet resolved:

Relevant contributor task: Identify duplicate issues.

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

Or, if the contributor(s) did something more than file an issue report, thank them for that specifically, e.g.:

Thank you for reporting this issue and [providing a patch/screenshot/steps to reproduce/etc.] [Why the extra thing they did was helpful.]

As part of the Bug Smash Initiative, we are triaging issues to try and identify duplicate issue reports.

I was able to reproduce this issue on [8.9.x/9.0.x/9.1.x HEAD] with the following steps:

1. Install Drupal core [8.9.x] with the [Standard] profile.
2. [Enabling modules, etc., other steps]

I located [#1234567] which appears to be the same issue. I'm marking this as a duplicate of that issue and I have [adding credits for/documenting contributors who should be credited from] this issue in a comment there: [#1234567-99].

Bugs that are Postponed (maintainer needs more info) where no additional information has been provided on how to reproduce the issue, no identifiable duplicate resolved the issue

Relevant contributor task: Triage an issue report

A. AND the triager ALSO could not reproduce the issue after a year.

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

Or, if the contributor(s) did something more than file an issue report, thank them for that specifically, e.g.:

Thank you for reporting this issue and [providing a patch/screenshot/steps to reproduce/etc.] [Why the extra thing they did was helpful.]

As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" [N] months ago [/back in 2018/whatever].

Like [previous commenter], I also was unable to reproduce the issue. I tested with the version of core from when this issue was filed with the following steps:

1. Install Drupal core 8.N.x [where N is old and was the prod release as of when they filed the bug, or was the version they chose originally] with the [Standard] profile. [Or: Check out a commit from around the date the issue was filed, with git checkout [hash]</code].
2. [Enabling modules, etc., other steps]

Since neither I nor [past contributor(s)] could reproduce this issue and since there weren't other steps to reproduce the issue provided since the issue was postponed in [month and year], I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active" [or "Needs Work" if it has a patch, etc.].

Thanks!

B. AND there are no steps to reproduce.

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

Or, if the contributor(s) did something more than file an issue report, thank them for that specifically, e.g.:

Thank you for reporting this issue and [providing a patch/screenshot/steps to reproduce/etc.] [Why the extra thing they did was helpful.]

As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" [N] months ago [/back in 2018/whatever].

There has been no activity here for N years and N months.

Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Full example comment to close an issue after the above time has elapsed:

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" more than 1 year ago.

Since we need more information to move forward with this issue, I am closing it.

Please feel free to reopen with more information.

Bugs that are no longer relevant to Drupal 8/9 (only reproducible on Drupal 7):

Thanks for reporting this issue. I was able to reproduce this issue on the Drupal 7.x HEAD as of this date with the following steps:

1. Install Drupal 7.x HEAD with the [Standard] profile.
2. [Other steps.]

I was not able to reproduce the issue using the same steps on Drupal [8.9.x/9.0.x/9.1.x] HEAD. Based on that, I think this issue affects only Drupal 7. Therefore, I'm moving it to the 7.x queue.

If there are different steps to reproduce the issue on Drupal 8.9.x or higher, add those steps to the issue summary and move the issue back to 8.9.x [or 9.1.x if it's a minor-only issue]. Thanks for your work on this issue!

[*Note: if/when D7 goes into an LTS mode, we should add some caveats at the end here and that would be when we use "Closed (outdated)"]

Bugs that was committed and re-opened open and can be closed:

This issue was committed N years ago in Drupal n.x and re-opened to [... add explanation ...]. A new issue has been created for the followup work [#issue number]. Therefor, marking this fixed at the time of the commit.

Add using commit-code-check script

Before uploading a patch or a pushing an MR it is good practice to run spelling and coding standards checks locally. Have a look at the <a href="https://www.drupal.org/docs/develop/development-tools/running-core-devel...">instructions for running the coding standard checks locally</a> so you can be sure the tests will run. It also has the advantage of saving resources, including money, for the Drupal association. There are real costs for running the tests.

Add interdiff instructions

To help reviewers, always add an interdiff, or a diff, whichever is appropriate. There are instructions for <a href="https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...">creating an interdiff</a>. If you think a diff is not needed, add a comment stating why.

Useful tags to add when triaging

• Bug Smash Initiative (of course) - because we touched it
• Needs reroll - if the patch is old
• Needs issue summary update - if there's a lot of conversation in the comments not covered in the summary
• Needs steps to reproduce - self explanatory
• Needs tests - if there's a patch with no tests
• Needs manual testing - if there's some conjecture about how to reproduce it
• Needs screenshots - if its changing CSS or UI

and we also remove tags that are duplicate other issue fields like category, component, status

See the full list of special tags