What is Triage Squad?
The training team Triage Squad are members of the Training Team who can help review, test, and triage GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull requests and issues for the Learn WordPress repository. The goal of this squad is to ensure that any newly opened issues are valid, and correctly labeled.
Any contributor is welcome to work on any open issue/review any open PR, the Triage Squad will merely facilitate this process.
Taking part in Triage Squad
Any active member of the WordPress training team can take part in Triage Squad triage sessions. Sessions take place bi-weekly (every two weeks) every Thursday from 07:00 UTC in the #meta-learn channel in the Make WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. See the meeting calendar for when the next triage session will happen.
Format of Triage Squad triage sessions
The session starts with the host using the Slack /here tool to announce the start of the meeting. This is also piped through to the #training channel in Slack. The host can then use the intro script (below) to initiate the session and welcome any attendees.
A note on /here. It’s not possible to paste the /here command into the Slack message area, you have to type it out for it to work. So the best way to do this is, is to type /here, and then copy and paste the first line of the Intro script afterward.
Intro Script
Welcome to the bi-weekly training team Triage Squad triage session.
These bi-weekly sessions are where we triage any open PRs, new issues, or content feedback awaiting triage, opened on the Learn WordPress GitHub repository. We usually hold this meeting at 07:00 UTC for 30 minutes every other Thursday.
Please comment on this :thread: if you’re joining us today, and let us know where you are from.
If you are new to Triage Squad, you can read about it in the training team handbook: https://make.wordpress.org/training/handbook/training-team-how-to-guides/triage-squad-guidelines/
Triaging newly created Pull Requests
The host starts by sharing the link for Pull Requests (or PRS) (https://github.com/WordPress/Learn/pulls) and looks for any newly created PRs. Untriaged PRs will typically not have any labels assigned to them.
To triage an open PR, the host shares the PR link and checks whether it needs testing, a review, or a refresh. If needed, the host can discuss these options with the meeting attendees.
Once a decision has been made, the host can apply the relevant [Dev] label:
- [Dev] Needs Testing
- [Dev] Needs Review
- [Dev] Needs Refresh
In the case of [Dev] Needs Testing or [Dev] Needs Review, the host should make a note to bring this to the next training team meeting, to find contributors to perform testing or a review. In the case of [Dev] Needs Refresh, the host can leave a note in the comments, asking the PR creator to refresh the PR, with the relevant reasons why
If required, the host should also apply the relevant [Component] label, and check that the PR has been added to the LearnWP Website Development project.
New PRs should have the Drafts (PRs only) project status, and PRs that are currently in review should have the In Review (PRs only) project status. When in doubt, leave it in the Drafts (PRs only) project status.
The host then shares a summary of the actions taken on the PR and moves on to the next one.
Triaging newly opened bugs
The host starts by sharing the LearnWP Website Development Project View, specifically the Awaiting Triage column (https://github.com/orgs/WordPress/projects/71/views/6), and works through the list of issues in the Awaiting Triage column.
To triage an issue, the host shares the issue link and tries to determine the next logical action for this issue.
Firstly, the issue should be checked for if it’s a bug or a feature enhancement.
If it’s an enhancement, the issue can be labeled [Type] Enhancement, and the relevant [Component] label added. Then the Awaiting Triage label can be removed and the issue has been triaged.
If the issue is a bug, the [Type] Bug and the relevant [Component] label should be added. If possible, the host or one of the meeting attendees should try and verify that the bug is a legitimate one. This can be done by testing this on the Learn.WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ site. Once these steps are complete, then the Awaiting Triage label can be removed and the issue has been triaged.
For either of these options, the host should also consider if this issue is a good first bug for a new contributor, and if so, apply the Good First Bug label.
As with PRs, the host then shares a summary of the actions taken on the PR and moves on to the next one.
Triaging Content Feedback issues
If there are no PRs or bugs to triage, then the session can be used to verify Content Feedback issues. Content feedback issues are essentially “bugs” on the Learn WordPress content.
The host starts by sharing the LearnWP Content – Feedback Project View, specifically the Awaiting Validation column (https://github.com/orgs/WordPress/projects/78/views/3), and works through the list of issues in the Awaiting Validation column, from oldest to newest.
The host then follows the process for Validating Content Feedback issues in the Training Team Handbook.
After a triage session
Sometime after the triage session, the host should gather the triage session notes and post them to the training team meeting agenda for the next week. The meeting agenda is usually posted one to two days before the training team meeting.
