Triage

Get involved in triage

To keep the issue list healthy, it needs to be triaged regularly. Triage is the practice of reviewing existing issues to make sure they’re relevant, actionable, and have all the information they need. Anyone can help triage, although you’ll need to be a member of the triage team for the Gutenberg repository to modify an issue’s labels or edit its title.

Join the triage team

The triage team is an open group of people with a particular role of making sure triage is done consistently across the Gutenberg repo. There are various types of triage which happen:

  • Regular self triage sessions done by members on their own time.
  • Organised triage sessions done as a group at a set time. You can review the meetings page to find these triage sessions and appropriate slack channels.
  • Focused triage sessions on a specific board, label or feature.

These are the expectations of being a triage team member:

  • You are expected to do some triage even if it is self triage at least once a week.
  • As you can, try to join organized triage sessions.
  • If you join the triage team to focus on a specific label or board, the expectation is that your focus will be there. Please make this known to fellow triage team members.

If you would like to join this team, simply ask in #core-editor Slack at any time.

Getting started

To start simply choose from one of these filtered lists of issues below. Note: You can find these filters by selecting the “Sort” option from the overall Issues page.

  • All Gutenberg issues without an assigned label. Triaging by simply adding labels helps people focused on certain aspects of Gutenberg find relevant issues easier and start working on them.
  • The least recently updated Gutenberg issues. Triaging issues that are getting old and possibly out of date keeps important work from being overlooked.
  • All Gutenberg issues with no comments. Triaging this list helps make sure all issues are acknowledged, and can help identify issues that may need more information or discussion before they are actionable.
  • The least commented on Gutenberg issues. Triaging this list helps the community figure out what things might still need traction for certain proposals.
  • You can also create your own custom set of filters on GitHub. If you have a filter you think might be useful for the community, feel free to submit a PR to add it to this list.

General triage process

When triaging, either one of the lists above or issues in general, work through issues one-by-one. Here are some steps you can perform for each issue:

  • First search for duplicates. If the issue is duplicate, close it by commenting with “Duplicate of #” and add any relevant new details to the existing issue. (Don’t forget to search for duplicates among closed issues as well!).
  • If the issue is missing labels, add some to better categorize it (requires proper permissions given after joining the triage team). A good starting place when adding labels is to apply one of the labels prefixed [Type] (e.g. [Type] Enhancement or [Type] Bug) to indicate what kind of issue it is. After that consider adding more descriptive labels. If the issue concerns a particular core block, add one of the labels prefixed [Block]. Or if the issue affects a particular feature there are [Feature] labels. Finally, there are labels that affect particular interest areas, like Accessibility and Internationalization. You can view all possible labels here.
  • Consider adding priority if you can confidently determine what the likely level should be:
    • Priority OMGWTFBBQ: Major issues that are causing failures and are reported frequently. Typically, these are issues that are critical because they break important behaviour or functionality. An example might be, “Unable to remove a block after it is added to the editor”.
    • Priority: High: Fits one of the current focuses and is causing a major broken experience (including flow, visual bugs and blocks).
    • Priority: Low: Enhancements that aren’t part of focuses, iche bugs, problems with old browsers.
    • Note that it’s on purpose that no priority label infers a normal level.
  • If the title doesn’t communicate the issue clearly enough, edit it for clarity (requires proper permissions). Specifically, we’d recommend having the main feature the issue relates to in the beginning of the title (example) and for the title to generally be as succinct yet descriptive as possible (example).
  • If it’s a bug report, test to confirm the report or add the Needs Testing label. If there is not enough information to confirm the report, add the [Status] Needs More Info label and ask for the details needed. It’s particularly beneficial when a bug report has steps for reproduction so ask the reporter to add those if they’re missing.
  • Remove the [Status] Needs More Info if the author of the issue has responded with enough details.
  • Close the issue with a note if it has a [Status] Needs More Info label but the author didn’t respond in 2+ weeks.
  • If there was a conversation on the issue but no actionable steps identified, follow up with the participants to see what’s actionable. Make sure to @ each participant when responding in a comment.
  • If you feel comfortable triaging the issue further, then you can also:
    • Check that the bug report is valid by debugging it to see if you can track down the technical specifics.
    • Check if the issue is missing some detail and see if you can fill in those details. For instance, if a bug report is missing visual detail, it’s helpful to reproduce the issue locally and upload a screenshot or GIF.
    • Consider adding the Good First Issue label if you believe this is a relatively easy issue for a first-time contributor to try to solve.

Generally speaking, the following labels are very useful for triaging issues and will likely be the ones you use the most consistently:

  • Needs Technical Feedback – when you see new features or API changes proposed.
  • Needs More Info – when it’s not clear what the issue is or it would help to provide additional details.
  • Needs Testing – when old bugs seem like they are no longer relevant.
  • [Type] Help Request – when someone is asking for general help with setup/implementation.

Release specific triage

Here are some guidelines to follow when doing triage specifically around the time of a release. This is important to differentiate compared to general triage so problematic, release blocking bugs are properly identified and solutions are found.

  • If a bug is introduced in a release candidate (RC) and it’s going to break many workflows, add it to the version milestone and flag in the #core-editor channel in WordPress.org slack.
  • If a bug was introduced in the most recent version, and a next RC hasn’t yet happened, ideally the developers can push to fix it prior to RC! The amount of push for a fix should scale proportional to the potential of breakage. In this case, add to the RC milestone and, if deemed urgent, ping in the #core-editor channel in WordPress.org slack.
  • If a bug wasn’t introduced in the most recent version, do not add a milestone. Instead, use labels like “[Priority] High” if it’s a pressing issue, and if needed you can call attention to it in the weekly core meetings.

Design specific triage

Along with the general triage flows listed previously, there are some specific additions to the flows for more design-centric triage for design minded folks participating in triage.

  • PR testing and reviews: this should be your first stop for daily self triage.
  • Needs design feedback: check if the issue does need design feedback and, if possible, give it. You can organise this by priority, project boards or by least commented. Once there are enough opinions, please remove this label and decide on next steps (ie adding the Needs Design label).
  • Needs design: Does it really need a design? Does this fit a focus? If it has a design mark as ‘needs design feedback’ to better categorize the issue.

Reminders:

  • Ask for screenshots as needed.
  • Ask for iterations and note any changes before merging.
  • If the issue isn’t in a board, check to see if it doesn’t fit in a specific focus.
  • If the issue/pull has not been prioritized yet, consider adding a priority to help move the issue forward.

For more detailed information about weekly design triage and to join in, please review this guide.

原文

最終更新日: