Background #
This issue provides a guide on how to analyze and update (in other words, triage)
major priority →
issues in order to make Drupal 8 more stable and plan the next phases of Drupal core development.
Definition of major priority issues:
https://www.drupal.org/core/issue-priority#major-bug →
Past major triage Contribution days:
Upcoming major triage Contribution days:
Goals #
At the end of major triage we should have:
Understand the current state of the issue #
Note that these instructions are specific to bugs. Tasks and feature requests should be handled differently.
We recommend that you keep a separate file of your notes, and the issue metadata (tags, status, etc) you are planning to change. Make an initial comment saying that you and the person you will be working with are at the Drupalcon Nashville sprint looking at this issue. Try to make the rest of the metadata changes to the issue in one issue update (if possible) rather than making a number of smaller updates (to cut down on the number of notifications). Document the results of each step.
Even if you only do some of the steps, something is better than nothing. The goal is to make forward progress, not solve the issue in a single comment.
- Work with a partner. Select an issue from your component's queue (below). Pick a component you are familiar with, it will make things easier.
- Read the whole issue, or at least the last few comments to understand the issue. Do so in less than 15 minutes.
- If you partly understand the issue, or if you have some questions about it, ask someone! You can ask one of the recommended contacts for the component, contributors who have worked on the issue, the contribution leads, or other contributors at the contribution or in IRC.
- If you do not understand the issue in less than 15 minutes of reading it, choose a different issue.
- Make note of:
- Who filed it (Do they have more than 20 commit mentions in Drupal 8? More than 100? Are they a maintainer for the subsystem, an initiative coordinator, or a core committer? See list of maintainers.) Their experience with Drupal 8 lends credibility and validity to the issue.
- When it was first created. If the issue is really old, then it has a higher chance of being not applicable.
- When it was last updated. The longer the issue hasn’t been touched, the higher the chance that the issue is not applicable.
- Tag the issue with the tag for the Contribution day (e.g. "Nasvhille2017") and comment that you are working on triaging it.
- Try to reproduce the issue in the 8.5.x (or latest) HEAD, either on simplytest.me or locally. (If you test locally, start clean and be sure you pull the latest changes from git. `git log` should show commits within the last day or so.)
-
If you can reproduce the issue, leave a comment indicating that you have confirmed that the bug is still present.
Document the steps to reproduce →
in the issue summary if they are not listed there already, and then go on to the next step.
-
If you cannot reproduce the issue:
-
Try to reproduce the issue using the version of Drupal from when the issue was filed. You may need to check a specific commit from a long time ago or even Drupal 7.x. (Use `git log --before=date` to find commits before a certain date.) Be sure to start clean.
-
If you can reproduce the issue using an older version of Drupal 8.x, try to figure out when and how the issue was fixed, and document what you find on the issue. Techniques you can use:
-
Search for "Fixed" and "Closed (fixed)" issues related to the issue.
-
Use `git log -S` or `git log --grep` to search for related commits.
-
Use `git bisect` to find the first commit where the issue is resolved.
-
4A. If you find a specific issue that fixed it,
mark your issue as a duplicate →
of the issue that fixed it, and move on to the next issue.
-
4B. If you can reproduce the issue in the latest version of Drupal 7 but not Drupal 8, post a comment indicating that the issue has been resolved in Drupal 8. Set the version to "7.x-dev" and remove the "needs backport to D7" tag if it is there. Move on to the next issue.
-
4C. If you still can't reproduce the issue, leave a comment indicating that you were unable to reproduce the issue in either the current version or the original version. Document the exact steps you tried (so the next contributor knows what did not work) and tag the issue with "Needs steps to reproduce". Move onto the next issue.
-
For issues that are still relevant (i.e. you were able to reproduce the bug),
identify any duplicate issues →
. If you close issues as a duplicate, go on to the next steps for the open major issue. (You can disregard the closed one(s) from now on.) Do a best effort to find duplicates. Timebox to less than 30 minutes.
- Determine if the issue summary is up to date. If it is not, tag the issue with "Needs issue summary update". You can also
update the summary with what you know →
.
-
If the issue has a patch,
determine whether the latest patch is still relevant →
. Try applying the patch on a local git checkout. If the patch does not apply, tag it "Needs reroll". Only if the patch applies locally should you send it for re-testing.
- Tag the issue with the
Triaged for core major current state →
issue tag.
If you do not finish triaging an issue
Sometimes triaging an issue can take a long time, especially if it is difficult to reproduce. If you don't finish triaging an issue, add a comment that explains what you found so far and which steps you completed, so that the next contributor can build from your work.
Flowchart diagram #
(
PDF version with example comments →
/ draw.io original)
Example comments #
Initial comment
Your initial comment should include:
- The usernames of the other contributors you are collaborating with. Make sure to type your co-contributors' usernames correctly!
- The contribution or event you are participating in.
- A link to this issue, using the issue link shorthand:
[#2474049]
- The username of anyone helping you as a mentor.
Example initial comment:
@contributor1, @contributor2, and I are working on triaging this issue at Event, following the instructions in
🌱
[meta] Major issue triage
Active
. @contributor3 is helping as our mentor.
Add the event tag with your initial comment.
Final comment
Your final comment should include:
- The exact steps you used when trying to reproduce the issue.
- The branches, releases, or commit hashes you tested with your steps, and what the results were on each.
- Links to any duplicate issues you find, using the
[#NNNNNNN] issue link shorthand (where NNNNNNN is the Drupal.org node ID for the issue). Also add the issues to the Related issues field.
- An explanation for any changes you make to the issue metadata (tags, status, version, etc.).
Some examples:
We were or were not able to reproduce the issue on the latest 8.5.x on simplytest.me. The steps we used were:
- Install Drupal 8.5.x with the Standard profile.
- Enable the Settings Tray module under the Experimental package.
- (etc.)
We confirmed that the patch in comment #17 still applies to 8.5.x and we have sent it for re-testing using the "Add test/retest" link under the patch test results.
or
The latest patch in #17 does not apply to 8.5.x HEAD, so it needs to be rerolled. For this reason, we're adding the "Needs reroll" tag and marking the issue "Needs work".
If the issue is fixed in HEAD but present in an older version:
However, we were able to reproduce the issue with those same steps using an older release (8.2.6) from when this issue was reported back in February of 2017. We looked into it more and determined that this was fixed by [#NNNNNNN], so we are closing this as a duplicate of that issue by adding it to the related issues and marking this "Closed (duplicate)".
If the issue cannot be reproduced at all:
We tried testing on the latest 8.5.x HEAD, 8.2.6 (the latest release as of when the issue was posted), and commit e496c7b3 (a commit on the day the issue was posted) and we were not able to reproduce the issue. The issue does not apply to Drupal 7 since the Settings Tray module was not added until Drupal 8.2.0-beta2. So, we need accurate steps to reproduce the issue in order to resolve it. Tagging "Needs steps to reproduce" and marking "Postponed (maintainer needs more info)" for those reasons.
Major triage queues #
For the first few contributors, here are a few issues tagged
Needs triage for core major current state →
that the committers determined could use verification. So the first contributors can look at those and potentially assess them.
Then, after that, contributors should team up with others, pick one component, and search for that component within this queue:
Drupal 8 major bugs that have not already been triaged →
.