Keeping up with the Gutenberg repository has been a slog for years. If you have ever tried to work out what is actually landing in the next major release by paging through a few hundred loosely related PRs, you know the feeling. It burns time that contributors and plugin developers would rather spend on code, and WordPress Iteration Issues are the part of the process meant to fix that.
There was never a shortage of work happening. The problem was that you could not see it in one place. Updates went missing or sat buried in a comment thread, and the confusion peaked right before Beta 1 every cycle. I have spent more than 14 years in WordPress internals, and a sloppy release process does as much damage as a bad patch. The new expectations for WordPress Iteration Issues go after exactly that.
What changed in 2026
An iteration issue does not replace a Trac ticket. It sits above the individual tasks and gives one feature a single thread you can follow. The latest Make Core updates also drop the habit of re-using old issues: every release gets a fresh one, tagged with the [Type] Iteration label.
For the feature side of this, I wrote up the Gutenberg 22.8 features separately. Shipping APIs that size is where standardized status updates earn their keep.
- Before the beta cycle starts, an iteration issue gets updated at least once a month.
- From one week before Beta and through the RC periods, that becomes weekly.
- When the release is tagged, the issue is closed instead of being carried into the next cycle.
What makes a WordPress iteration issue useful
Plenty of the issues I have read were really just an automated changelog with a date on it. That tells you nothing the commit log would not. An update is worth reading when it says what is blocked, what is landing, and what is probably slipping to the next milestone. There is now a new Iteration issue template that asks for those things up front.
The template follows earlier work to provide more clarity in the Gutenberg repository, and the direction there is automation rather than someone hand collating status every week. Nobody can plan against a release whose state they cannot see.
What belongs in an update
A useful one covers:
- Named contributors who are actually on the hook for posting updates.
- A scope of work that matches this release timeline rather than the whole roadmap.
- Explicit design requests, raised early instead of in the last week.
- A summary of the decisions already made, so the comments stop relitigating them.
If you want to know who is driving this, the 2026 WordPress Core Team Representatives post covers the people involved.
/**
* Conceptual Logic for Tracking Iteration Velocity
* This isn't just about labels; it's about avoiding the "Last Minute Rush"
* that breaks CI/CD and stability.
*/
function bbioon_check_iteration_health( $release_date, $last_update ) {
$days_to_beta = ( strtotime( $release_date ) - time() ) / DAY_IN_SECONDS;
// If we're within 7 days of Beta, we need weekly (7-day) updates.
if ( $days_to_beta < 7 && ( time() - strtotime( $last_update ) ) > WEEK_IN_SECONDS ) {
return 'CRITICAL: Iteration update overdue for Beta crunch.';
}
return 'STABLE: Process followed.';
}If tracking this eats hours you would rather spend elsewhere, I can take it on. I have been working with WordPress since the 4.x days.
What this means day to day
None of this is glamorous work. Someone still has to sit down each month and write what happened, and the payoff only shows up when a plugin developer reads it and gets a straight answer. WordPress Iteration Issues are where that answer is supposed to live, so if a feature you depend on has a stale one, say so in the thread.
