Dev-squad GitHubGitHubGitHub 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/ triage: Thursdays 07:00 UTC
The training team developer squad (or dev-squad) are members of the Training Team with development experience, who can help review, test, and triage GitHubGitHubGitHub 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 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.
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 SlackSlackSlack 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.
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.
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.
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.
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.orgThe 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.
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.
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.