-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
As a new triage team member, I wanted to offer some general updates to the triage documentation to add in more clarity, relevant links, and edits to the structure. There are no major changes to the overall triage process!
- Loading branch information
Showing
1 changed file
with
46 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,78 +1,68 @@ | ||
| ## 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. | ||
| 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 | ||
| * Organised triage sessions | ||
| * Focusing on a specific board, label or feature to triage | ||
| * 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](https://make.wordpress.org/meetings/) to find these triage sessions and appropriate slack channels. | ||
| * Focused triage sessions on a specific board, label or feature. | ||
|
|
||
| If you would like to join this team, you can through asking in #core-editor Slack at any time. | ||
| These are the expectations of being a triage team member: | ||
|
|
||
| These are the expectations of being a 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. | ||
|
|
||
| * As a member of the triage team, you are expected to at least once a week do some triage even if it is self triage. | ||
| * Some people might join this team to focus on a specific label or board, in that case their focus is there. | ||
| * Try and join triage sessions. | ||
| If you would like to join this team, simply ask in #core-editor [Slack](https://make.wordpress.org/chat/) at any time. | ||
|
|
||
| ## Getting started | ||
| To start simply choose from one of these filtered lists of issues: | ||
| 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](https://github.com/wordpress/gutenberg/issues). | ||
|
|
||
| * 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 issues Triaging this list helps the community figure out things like traction for certain proposals. | ||
| * All Gutenberg issues [without an assigned label](https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+no%3Alabel+sort%3Aupdated-asc). 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](https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc) 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](https://github.com/wordpress/gutenberg/issues?q=is%3Aissue+is%3Aopen+comments%3A0+). 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](https://github.com/wordpress/gutenberg/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc) 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. | ||
|
|
||
| ### Triage itself | ||
|
|
||
| ### 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). | ||
| ** 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 | ||
| * Consider adding priority if you can: | ||
| ** 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: usually placing in that project board. | ||
| *** Major broken experience (including flow, visual bugs and blocks). | ||
| ** Priority: Low: | ||
| *** Enhancements that aren’t part of focuses. | ||
| *** Niche bugs. | ||
| *** Old browsers | ||
| ** Note that no priority label infers normal. | ||
| * If the title doesn’t communicate the issue, edit it for clarity (requires proper permissions). | ||
| * 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, ask the reporter to add those if they’re missing. | ||
| * 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](https://github.com/WordPress/gutenberg/labels). | ||
| * 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](https://github.com/WordPress/gutenberg/issues/6193)) and for the title to generally be as succinct yet descriptive as possible ([example](https://github.com/WordPress/gutenberg/issues/6193)). | ||
| * 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. | ||
| * 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. | ||
| * 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. | ||
|
|
||
| For triaging there are some labels which are very useful: | ||
| * Needs Technical Feedback - you can apply them 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 - it’s useful for old bugs where it seems like they are no longer relevant | ||
| 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. | ||
|
|
||
| ## Design specific triage | ||
| Along with the general triage flows listed previously, there are some specific additions to the flows for more design-centric 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. | ||
|
|
||
| * PR testing and reviews: ideally this is your first stop, particularly in daily self triage. | ||
| * Needs design feedback: check this does need design feedback and if possible give it. You can organise this by priority, project boards or by least commented. | ||
| ** Ask for screenshots to see if unable to. | ||
| ** Ask for iterations and note need to change before merging. | ||
| ** Once enough opinions remove the label and either go to needs design. | ||
| ** If this isn’t in a board, check it doesn’t fit in a specific focus. | ||
| ** If the issue/pull has not been prioritized yet, consider adding a priority. | ||
| * Needs design: | ||
| ** Does it really need a design? | ||
| ** Does this fit a focus? | ||
| ** If it has a design mark as ‘needs design feedback’. | ||
| For more detailed information about weekly design triage and to join in, please [review this guide](https://make.wordpress.org/design/handbook/workflows/weekly-gutenberg-design-triage/). |