In 2023, I had the privilege to contribute to the WordPress 6.3 release squad on the Editor Triage team. It was my first round of participating and for a while I was quite lost, as to what to do and how to see progress, or what my teammates were working on, so we can coordinate.
I started taking notes. I post them on my personal blog, as it is a work in progress. I could be the groundwork for a new Core Handbook page, for now, this is a good place as any to house this. I’ll update the post with additional insights, once I have them 😉
“An Editor or Core Triage’s role is not to ensure all bugs and issues are fixed but to identify what needs to be fixed and share the status of it.” (Hector Prieto)
Current Release Documentation in Make Core Handbook
- Set up and manage the release project board on GitHub,
- Triage incoming bug reports for issues that need fixing during the release cycle.
- Run regular triage sessions in WP Slack, both synchronously and async.
- Ping tech leads and feature developers as required about any urgent bugs.
This document is a more elaborate description of the work, how I experienced it and my thoughts on how I can get a better grasp on what’s the work in front of me and how to organize division of labor or at least communicate progress beyond the board.
Prerequisites / Needed skills
Set up a local development environment for Gutenberg: Documentation There is some documentation here, but it’s a bit outdated. It’s in the process of being updated.
Creating a new project board
- Use the Project Template Editor Tasks for Major WordPress Release
- Click on Use this template to create a new board
- update the title of the board.
The new project then needs to be link to the Gutenberg repo from the Project’s tab
Continuation of Project boards.
The release work on the team starts with migrating punted items from the previous release into the Triage column of the next major release’s project board.
Use the Project in the sidebar of the single issue or PR
- Check the new board and uncheck the old board
- Then select Triage from the drop-down menu
In this video, the switcheroo is demonstrated. https://recordit.co/0dBJ2yDpSL
It probably helps to leave a note on the previous release project board:
Note: Punting is a sports metaphor. The term is used in American football. If you punt something, you decide not to do or include it. It’s “punted” to be included in the next release.
The board is open:
The Roadmap post.
A Roadmap post identifies the features, enhancements, and bug fixes that are slated for the release. Ideally, it’s a shared understanding from Release leads,Core and Editor Tech leads (Example 6.3). It contains the overview and tracking issues for features and updates.
Members of the Editor Triage release team would need to become quite familiar with the features.
A fortnight before Beta 1 I created Google Doc with the status of the Roadmap 6.3 features:
Comments about this document:
“That’s incredibly helpful 
Project Board (Example 6.3)
The Editor Triage release team watched the list of issues coming in on the Gutenberg GitHub repo, together with the ongoing Triage team. Issues that concern a feature that’s on the roadmap for the release are added to the project board > Triage column
If it’s obvious that it needs to be fixed, it can go right into the “Todo” column.
Before the Beta 1 release that can be issues labeled Bugs or Enhancements
During Beta release cycle the regular triage sessions in the core-editor channel are suspended, and replaced with async triage sessions to handle the Release Project board, especially the Triage and Needs discussion column, but also the Todo and if necessary the In progress, column
A async session look is handled in #release squad channel / or core editor channel.
Each PR /Issue is added into a message and then the Triage and Tech lead team members use emojis to ‘vote’ on the next step.
Here is an example from 6.3
Issues that are punted, meaning they won’t be fixed for this release are placed in the columns “Punted to the next WordPress point release”, here 6.3.1 or to “Punted to next WordPress major release”, here 6.4.
Note: I am confused as to what could make and issue put on priority for a minor release and what criteria is used to punt it to the next major release.
An issue is placed in the In Progress column once a PRs is created to fix the issue. The PR is added to the board as well, to the “Needs Review” column.
In the latest triage before RC 1, I went through the In progress list and paired it up with the PR to see what needs to be done. I figured if an PR needs to be in the release Tech leads need to review the PR first or at least add the “Backport to WP Beta RC’ label to merged items.
Timeline of work / Tasks regarding the release cycle:
- Closely monitor all issues in the Gutenberg Github repo as we get closer to beta 1
- When beta 1 hits, I then watch even more intensely all the way through the release but in particular to RC1.
- There’s a fair amount of shifting and iteration ahead of RC1 sometimes to get fixes in.
- Ensure proper labeling and add issues to the board: https://github.com/orgs/WordPress/projects/103/views/1
- Follow up with the developer if any issue persists in the beta release for an extended period
- If we need to escalate an issue that isn’t being fixed, we can alert the Editor tech leads:
- Sometimes we have to do some work to find devs to fix issues but usually it’s in coordination with others.
Testing
During RC phase only bugs that occured during Beta phase will be fixed.
“This issue is already present in 6.2 and we’re in RC phase for 6.3 so let’s leave it out for now.” – needs to be explained in more details.
For WordPress 6.4 we scheduled a Kick-off meeti
Leave a Reply