Voting starts in March for the Drupal Association Board election.
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 sprints:
- DrupalCon Los Angeles
- DrupalCon Barcelona
- DrupalCon Mumbai
- DrupalCon New Orleans
- DrupalCamp New Jersey
Upcoming major triage sprint:
At the end of major triage we should have:
- A lot of issues that are marked duplicate/cannot reproduce problem (See Current State steps #3 & #4).
- A lot of issues tagged as Triaged for D8 major current state.
- Some issues that are bumped to critical.
- Some that are postponed to 9.x.
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 Florida Drupal Camp 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).
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 sprint leads, or other contributors at the sprint 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 sprint (e.g. "FLDC17") and comment that you are working on triaging it.
- Try to reproduce the issue in the 8.4.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.
- If you find a specific issue that fixed it, mark the issue as a duplicate of the issue that fixed it, and move on to the next issue.
- 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.
- 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, 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 D8 major current state issue tag.
Major triage queues
For the first few sprinters, here are a few issues tagged Needs triage for D8 major current state that the committers determined could use verification. So the first sprinters can look at those and potentially assess them.
Then, after that, sprinters 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.