For WordPress 7.0, I co-led the Triage squad with Jean-Baptiste Audras (@audrasjb). It was my first time in the role, so I learned a lot from Jean-Baptiste, who had a much clearer understanding of how the release process worked. He helped me see what mattered most at each stage. If this is your first time in the role, having a more experienced person alongside you is invaluable.
Triage on a release is also shared work, not the triage squad’s alone. A lot of the role is just filling whatever gaps are open at the time, so what any one person touches varies.
I’m writing this article to share how I approached the role and what I learned along the way. My goal with this post is to give future Triage Leads and supporters a practical reference for upcoming WordPress releases, sharing how the cycle looked from the triage role, how priorities evolved throughout the release cycle, and the strategies that helped me keep the milestone on track.
Table of Contents
- What triage means in a release
- How priorities shift across the cycle
- Punting without guilt
- Working with committers
- How Gutenberg fits in
- Running bug scrubs
- The queries that did the work
- Long-running tickets
- Speeding it up with tooling and AI
- Communication and people
- Final thoughts
- References
What triage means in a release
In a release, triage answers one question: what gets into the milestone? This is much more specific than the everyday sense of triaging as organizing and prioritizing work.
The handbook calls the everyday version of this work Bug Gardening. Release triage is that same work pointed at a deadline. The milestone is the constraint, and I learned to measure every decision against one thing: does this help the release ship on time?
The way I came to picture the role was as someone deciding which of the tasks already slated for the release were mature enough to ship and which needed more time.
For every ticket on the upcoming version, I was answering one question — is this going to make it? When the answer was yes, I’d keep it, chase it, and help get it to the finish line. When it was no, I’d move it to the next milestone, leave a note explaining why, and move on.
How priorities shift across the cycle
What mattered changed a lot as the release moved through its phases — the handbook’s How the Release Cycle Works and Releasing Major Versions lay out the full structure. Here’s how each one felt from the triage seat.
Before Beta 1: features are still open
Up to Beta 1, the milestone still takes new features and enhancements. That includes the long-running ones tracked in Trac as task (blessed). Committers usually own those, so I kept an eye on their progress rather than touching them.
In this phase my focus was:
- The milestone 7.0 tickets, sorted by oldest activity first, so the most stalled ones rose to the top.
- Enhancements and feature requests specifically. Defects could wait for a later phase.
- Punting anything that hadn’t moved in about three weeks once the deadline was close. A contributor can always reopen it for the next version.
In practice that was a single Trac query I kept open: open non-bug tickets on milestone 7.0 — everything that isn’t a defect, with Build/Test Tools filtered out, grouped by severity.
On the Gutenberg side, work happened on the “WordPress 7.0 Editor Tasks” project board Triage column, and on watching which editor features needed to land in the last Gutenberg release before Beta 1. That release is the cutoff for editor features.
Beta 1: the freeze
Beta 1 is the feature freeze. After it, no new features or enhancements go in, and the triage job changes its focus.
The first task is to clear the milestone. Any open enhancement or feature request without the commit keyword is now a punt candidate, so we’d query for them and punt the lot to the next major in one pass. Blessed tasks and Build/Test Tools tickets stay out of that query: they aren’t bound by the freeze and can land later in the cycle, so they’d only clutter it. The handbook’s Releasing Beta and RC Versions page describes the same cleanup from the release lead’s side, including converting anything still considered essential into a task (blessed).
Gutenberg freezes too. From Beta 1 on, the only editor changes that will reach the release are bug-fix PRs carrying the Backport to WP X.X Beta/RC label.
After Beta 1, through RC: bugs only
Now the job flips. Instead of tracking what might ship, the focus is what’s broken in the build people are testing. The query becomes open 7.0 defects, oldest activity first. For each bug, the aim is to move it one step closer to a fix. Depending on where it’s stuck, that could mean confirming it still reproduces, flagging it as a regression, nudging the author to refresh a stale patch, asking for testing, or connecting a ready patch to a committer who can land it.
RC1 is the last stop for blessed tasks. After it, the release is in stabilization, and only bug and regression fixes go in.
Punting without guilt
This was the habit that mattered most, and the one that took me the longest to get comfortable with.
A milestone stuffed with half-finished features is worse for everyone than a smaller, stable one. Punting a ticket isn’t rejecting it. It just means “not ready for this version.”
Whenever I reviewed a ticket, I looked for three signals: no recent progress, a looming deadline, or a discussion stuck in circles. When a ticket showed those signs, it was usually clear it wouldn’t make the release. In those cases, I’d leave a public comment in Trac explaining the move and the reasoning, update the milestone, and move on. That comment did a lot of quiet work: it notified subscribers, created a record of the decision, and made it clear the change was intentional, not an oversight.
Where you punt to is a judgment call. The Leading Bug Scrubs handbook page suggests Future Release, so tickets don’t roll from one version to the next without anyone owning them. We often punted straight to the next major when we genuinely expected the work to pick back up. Either way, nothing’s permanent. If someone turned up with a working patch, the ticket could come back, and that’s a good problem to have.
Working with committers
I never commit code as a triage lead, and most contributors can’t either. That distinction turned out to be central to the role, so it’s worth being precise about.
A contributor can take a patch a long way: write it, review someone else’s, test it, and mark it ready on the ticket. What a contributor can’t do is land it. In WordPress core, only a committer — someone with commit access to the repository — can actually run the commit, and it’s a manual step done by hand. (New committers are even asked to get a peer review before their first few commits.)
That’s why a ticket can be patch-ready, tested, and flagged as good and still go nowhere. It’s waiting on one of the relatively small group of people who can commit it. Closing that gap — making sure ready work doesn’t stall — is one of the most impactful things a triage lead can do.
Knowing the last few steps a ticket goes through before it ships helped me spot which ones to chase. Once a patch is judged ready, the commit keyword goes on the ticket (I’d add it during a scrub once it was confirmed). A committer then picks it up and commits it, and the ticket closes. So any ticket still carrying commit while still open is stuck between “approved” and “shipped” — exactly the queue I needed to push on.
Committers are approachable, so I just asked directly, in Slack or on the ticket. Gutenberg is lighter here, since shipping is an approval and a merge button, which is why this connector role matters most on the Core side.
How Gutenberg fits in
The Gutenberg side took me longer to understand than the Trac side. The part I already knew: a major WordPress release bundles a set of Gutenberg plugin versions, and the last one it includes has to be published before Beta. Where I got stuck was after Beta 1 — once that Gutenberg version was frozen, what was left to triage on the editor board, and how did those items still reach the release?
WordPress doesn’t ship “the Gutenberg plugin” at all. Core syncs the @wordpress/* npm packages at a point in time, so a release lines up roughly with the last Gutenberg plugin release before Beta 1. For WordPress 7.0 that was Gutenberg 22.6 (6.9 had shipped 21.9). After the freeze, individual fixes still need a way in, and that way is the Backport to WP X.X Beta/RC label. A labelled PR gets cherry-picked from Gutenberg’s trunk onto the release branch. The label, not a newer plugin version, is what pulls a fix into the frozen build.
For Gutenberg, triage happens on the project board created for each release, and the job is to help its items move forward: across the columns, or into Punted to X.X.1 or Punted to X.Y when they’ve stalled. From a triage perspective, how a change will ultimately reach the release — bundled in the Gutenberg version, or carried in later by a backport label — matters less than keeping it moving.
In the last major WordPress releases, the Triage Leads cover both Trac and the editor board, and the Tech Leads handle the technical and backport calls. The full mechanics live in the Block Editor Release Process page.
Running bug scrubs
A scrub is a scheduled triage session that usually happens twice a week during a major release cycle. The canonical guide is Leading Bug Scrubs, and it makes a reassuring point: you don’t need to be a committer, or even hold special permissions, to lead one. A good session just needs a clear stopping point, whether that’s a ticket count or about an hour.
A few things I learned the practical way.
Sort the schedule out early, then expect it to move. For 7.0, we ran two weekly slots in #core, on Tuesdays and Thursdays, scheduled to suit contributors in different time zones. The schedule was published in a Make Core post. In practice the sessions moved around constantly, for release parties, WordCamps, and travel. Two things we did kept that manageable: swapping coverage with the co-lead whenever one of us couldn’t make a slot, and editing the published post when a session moved rather than only mentioning it in Slack, since the post is what people actually check.
Access matters before the first session. Before a first scrub two things need to be in place: the ability to summon the channel to announce the session (/here command), and permission to set the gated Trac keywords, especially commit. Both are worth sorting out ahead of time.
The session itself stays simple. It opens with a short message carrying the <bug-scrub> tag — something like “@here Welcome to WordPress 7.0 <bug-scrub>“ — so the start and end are easy to find later. Each ticket gets posted so Slack unfurls it. The most stalled tickets come first, since those are the ones most likely to need a decision. On long threads with many patches, the latest patch is the baseline, and every decision gets recorded as a Trac comment, not just in Slack. To read a ticket’s state quickly, I leaned on a small Chrome extension I built, WP-Trac Triager (there’s a short write-up here).
Leave specialist calls to the component teams. Accessibility (#accessibility, Tuesdays 15:00 UTC), Performance (#core-performance, every other Tuesday), and the Test Team (#core-test, the second Wednesday of each month) run their own scrubs, all listed on the Meeting Calendar. When a ticket is really their call, hand it to them rather than settling it in the general session.
One last thing I noticed late in the cycle: once the milestone is nearly empty, a scrub stops earning its slot. It’s fine to scale the cadence down rather than hold a session for its own sake.
The queries that did the work
The commit keyword is the signal that a ticket is on track. When it’s missing on an open ticket near the deadline, that ticket is a punt candidate.
Here are the actual 7.0 queries I used. They can be adapted by changing the milestone:
- Alpha, non-bugs: open non-bug tickets on milestone 7.0
- Beta and RC, defects only: open bugs on milestone 7.0
Gutenberg doesn’t have Trac’s query language, so the equivalents are GitHub views: the project board, the open backport PRs, and the open [Type] Bug issues.
For someone new to Trac itself, The Bug Tracker and Trac Workflow Keywords are the references to start with.
Long-running tickets
Some threads are longer than this article. The way through them is roughly the same each time. The current state is usually in the last few comments, so the bottom is the place to start. The latest patch is the baseline. The real blocker is usually just one thing: missing tests, an accessibility concern, an unresolved API decision, or no committer review, for example. From there, the move is to ping the last active person (or the owner or the reporter) with a specific question rather than a vague nudge.
If a ticket has been going in circles for years, it’s a punt candidate. A release cycle isn’t the place to settle a fundamental design or implementation disagreement.
Speeding it up with tooling and AI
The slowest part of triage is reading, and two things helped me cut through it.
The first is the WP-Trac Triager extension I mentioned, which shows a ticket’s state at a glance. The second is an AI assistant, in my case Claude Code, for the reading itself. I’d ask it to summarize a long thread down to its current state and the actual blocker, and to suggest the workflow keywords that probably applied so I could confirm them rather than dig through my memory. Jon Surrell’s wordpress-trac skill does a version of this end to end.
One thing worth remembering: a lot of the real discussion lives in the linked PR, not in the Trac ticket. When a ticket points at a PR, that’s what to feed the agent (or read yourself) — summarizing only the Trac comments will miss where the real decision happened.
Communication and people
Triage is as much about communication as it is about queries. A few things I’d pass on.
Be direct. Pinging someone a few times during a release isn’t rude; it’s part of the job. When you punt, do it publicly in Trac, so there’s a record and the watchers get notified. Before a scrub or a hard call, post in the version’s release channel (for us, #7-0-release). It often surfaces context you didn’t have, like someone already working on the ticket. For procedural questions, #release-leads is the better room, since that’s where the veterans are. And don’t wait for perfect information. If a ticket is silent and the deadline is near, make the call.
The people you’ll lean on most are:
- the release lead, who has the final say on what ships
- your co-lead, who you’ll split coverage with by time zone, so check what they’ve already scrubbed
- the committers, your path to actually landing a fix
- and the component maintainers, for when something needs specialized technical judgment
The Release Team and Focus Leads page has the full roster, and it’s worth reading the Post & Comment Guidelines before you post on Make Core.
Final thoughts
If this is your first time as co-lead of the Triage squad in a major WordPress release, expect to learn most of this by doing it. A few things make the first cycle easier:
- Don’t hesitate to ask questions. The community is genuinely supportive and always willing to help.
- Keep a few copy-paste notes for the things you’ll write over and over, so you’re not composing them live mid-session.
- Don’t be afraid to punt. The real risk in a first release isn’t punting too much. It’s leaving half-finished work in the milestone because you didn’t want to make the call. Every ticket you route correctly, in or out, helps the release ship clean.
References
Everything here builds on the Make WordPress Core Handbook. The two to read first:
- Leading Bug Scrubs — how to run a scrub
- Bug Gardening — the day-to-day ticket work triage builds on
By topic: The Bug Tracker and Trac Workflow Keywords; How the Release Cycle Works and Releasing Beta and RC Versions; Block Editor Release Process; Release Team and Focus Leads; Post & Comment Guidelines; and the Glossary.
Live resources: the Trac reports, the dev-feedback list, and the Meeting Calendar.
Props to @adamsilverstein for reviews and feedback
Leave a Reply