Dev-squad guidelines

What is dev-squad?

The training team developer squad (or dev-squad) are members of the Training Team with development experience, 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. pull requests and issues for the Learn WordPress codebase. The goal of this squad is not specifically to work on any of these items, but merely to help move them along. 

Any contributor is welcome to work on any open issue/review any open PR, the dev-squad will merely facilitate this process.

Top ↑

Taking part in dev-squad

Any active member of the WordPress training team can take part in dev-squad triage sessions. Sessions take place on the second and fourth Thursdays each month from 07:00 UTC in the #meta-learn channel in the Make WordPress SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at See the meeting calendar for when the next triage session will happen.

Top ↑

Format of dev-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.

Top ↑

Intro Script

Welcome to the weekly training team dev-squad triage session.

These weekly sessions are where we triage any open PRs or new bugs 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.

Top ↑

Triaging newly created Pull Requests

The host starts by sharing the link for Pull Requests (or PRS) ( 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.

Top ↑

Triaging newly opened bugs

The host starts by sharing the LearnWP Website Development Project View, specifically the Awaiting Triage column (, 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 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. 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.

Top ↑

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 (, 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.

Top ↑

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. 

Last updated: