[meta] Major issue triage

Welcome to the major issue triage sprint at DrupalCon Los Angeles!

@heddn, what would the two tags mean?

1) Triaged D8 Major Current State
2) Triaged D8 Major Acceptance Criteria

Thanks @heddn, I see. So the first tag is about ensuring the issue's relevance, and the second is about ensuring the issue's actual eligibility to be committed to whatever branch it is filed against (8.0.x or 8.1.x). That way, all contributors can help "narrow the funnel" into a queue for experienced contributors to assess the issue in terms of the Allowed changes policy.

One option is that we could use simply "Triaged D8 major" for the second category (meeting the acceptance criteria), since it most closely corresponds to "Triaged D8 critical". The main difference is that only committers could tag issues as "Triaged D8 critical", but that was due largely to the fact that it so directly determined the release date. For major issues, I think we can encourage others to use this tag as well. The "Needs release manager review" tag can always be added if there is some doubt.

Based on that, I'd suggest the first tag be instead "Needs D8 major triage". That way, we would crowdsource creating a queue of issues that are still relevant, but need to be assessed for whether they can go into 8.0.x / 8.1.x / etc.

Removing the beta eval item from the steps since we're not in Kansas anymore. :D Also reduced the RC bullet to link to the allowed changes doc and tags now that we have those.

And also linking that in the step about assessing the issue for patch/minor/major version inclusion.

And fixing the list formatting a smidge.

And updating the background information for RC as well.

Add links for commit mentions and maintainers.

Updated to remove acceptance criteria steps for now -- I will create a separate meta for that.

Welcome to DrupalCon Asia 2016 major issue triage!

The flowchart is not up to date, so commenting it out for now.

For DrupalCon Asia, we'll start from the oldest issues in the major bug queue. Here is a link:

https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

(Edit: Added a tag for issues to skip)

Thanks to everyone who participated in the DrupalCon Asia major triage sprint! I've updated the relevant major issues to add proposed issue credit for triagers where appropriate. We clarified the status of some of the oldest major bugs in the queue.

So the flow charts attached above are actually flipped around; the one labeled "Drupal 8 Triage Major Issues Acceptance Criteria Flowchart" is actually the current state flowchart and vice versa. Oops! :)

In the mentoring meeting we discussed updating the flowchart in preparation for DrupalCon NOLA. The acceptance criteria workflow (in the attachment labeled "current state") was pre-release and so is not applicable anymore. However, we are improving the process now so that core committers and subsystem maintainers collaborate to assess those criteria, so we don't need to worry about updating that flowchart.

Starting with DrupalCon Asia, we are focusing on triaging for current state at sprints. The current state flowchart (the one labeled "acceptance criteria") is very close to accurate still and just needs a couple updates:

1. The step that says "Can reproduce in 8.0.x?" should be changed to "Can reproduce in 8.2.x?".
2. The step that says "Tag 'Current State Triage Barcelona2015'" should be changed to "Tag 'Triaged for D8 major current state' and with sprint tag".

Alright, here is the updated flowchart.

I realized also that the endpoints for non-reproducible issues were actually not marked as such and instead pointing to the bubble to tag the issue as triaged. Attached fixes that, plus also adds in the steps to check whether the patch applies.

Fiddling the arrows to make them less confusing.

@mikeryan, @alimac proposed neworleans2016. Using that for now. :) (But yum, canola.)

And welcome to the New Orleans major triage sprint!

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.

Thanks everyone for helping triage major issues at New Orleans! I've found the following usernames of major triage sprint participants for the NOLA sprint:

1. cilefen
2. valthebald
3. catapipper
4. dbyers55
5. oadaeh
6. Stephanie_42
7. AndrewHD
8. jdelvillar01
9. gabesullice
10. ecrown

I think that is missing several sprinters; let me know via my contact form if so. Also be sure to comment on any issue you helped triage so I can make sure you are credited.

Adding a current table to the summary.

We are sprinting on major triage in a week at DrupalCamp New Jersey.

@pwolanin So sprinters should not actually be downgrading the issues in most cases if they are still relevant. The process is to tag them once they're confirmed to be relevant and then the maintainers confirm the priority (or not) since that can take a lot more time to understand. See flowchart.

That said the priority definitions are obviously helpful! Somehow that is not linked in the summary already. I will add it: https://www.drupal.org/core/issue-priority#major-bug

Recent data.

For DrupalCamp NJ there are just a few of us so we are coordinating which issues we are triaging in a spreadsheet:
https://docs.google.com/spreadsheets/d/1HIiqu9WPmjRuZc5qG_sn0pwbfYLtoFg5...

Great work so far!

We had a good sprint at DrupalCamp Montréal this weekend. A couple followups we identified:

1. Put this issue link at the top of the PDF and give it a slightly increased margin.
2. Move instructions on how to identify when an issue was introduced into their own handbook page, and link the handbook page.

I am adding the link to the original, editable draw.io version of the flowchart to the summary, since I keep losing track of it.

We talked about adding sample comments that people could use as templates. I typed up this:

Initial comment

@contributor1, @contributor2, and I are working on triaging this issue at Event, following the instructions in #2474049: [meta] Major issue triage.

Final comment

We were or were not able to reproduce the issue on the latest 8.5.x on simplytest.me. The steps we used were:

1. Install Drupal 8.5.x with the Standard profile.
2. Enable the Settings Tray module under the Experimental package.
3. (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.

Edit: added another example.

Made some changes to hopefully make the flowchart easier to read and less overwhelming. Also added the step numbers to the items.
https://www.draw.io/#G0B6pfQiiJgt4GRVIyZnZOd2NFQzg

@rachel_norfolk Yep. The detailed instructions in the summary Maybe this text would be more clear? Seems to fit the bubble:

4A. Find the issue that fixed it; close your issue as duplicate with a comment.

I also updated the corresponding step in the summary with similar wording and a link to https://www.drupal.org/contributor-tasks/duplicates. (It was linked in a different part of the instructions, but not there.)

(Removing "some issues that are postponed to 9.x" from the summary since this actually should almost never be the case with the continuous upgrade path and deprecation policy.)

Adding a list of what the initial and final comments should include along with the examples.

One task that someone could do is to create a contributor task handbook page for "Determine when a change was introduced in Drupal core". This would allow us to reduce the "text overload" in the summary a bit. The starting point would be these bullets:

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

The handbook page could also incorporate links to references on the relevant git commands. git blame and git log -L could also be added to the strategies for the handbook page. (They are less relevant for triage where the contributor might not know which hunk of code is relevant, but definitely relevant to the topic overall.

(Reordering the added sections a little.)

I updated the flowchart PDF to include the example comments on the second page, so we can print it as a two-sided handout at sprints.

Updated queues.

(Code filter and issue link filter don't seem to be ordered correctly.)

Updating the IS for new tag names.

Something we should have done from the get-go is have child issues per event, since a lot of the work that goes into triage ends up in non-creditable statuses (duplicate, cannot reproduce, etc.). I'm working on adding those children now, although retroactively crediting participants years later will take some archaeology. :)

I went ahead and created those issues and credited some of them the best I could. Ran out of steam. Active children still need their credits populated; NW issues have some credits but are missing others. Fixed issues have all or most participants and mentors credited.