Build script friction; beta testing discussed

On June 5, 2026, Core Committers in attendance (including emeritus) at WordCamp Europe in Kraków, Poland gathered for a brief informal meeting.

There was no formal agenda, but a few goals for the meeting were mentioned at the beginning:

• Allow newer committers to meet more senior ones.
• Allow anyone to raise questions, concerns, or suggestions that have been on their minds.
• Just spend some time together chatting and getting to know each other.
• Discuss short and medium term challenges.

Below are some brief notes from discussions that happened following Chatham House Rule.

Reducing Friction Between Code Bases

The meeting started by discussing the recent changes to the build scripts in both wordpress-develop and gutenberg aimed at making it easier to sync the changes from gutenberg on GitHub into wordpress-develop in SVN.

• It was painful at first, but the most disruptive initial issues have been addressed.
• The svn:ignore properties are still out of sync with the changes made to .gitignore.
• #64971 is open to address this.
• This is very easy to miss due to differences between SVN and Git.
• This process should be a reoccurring task.
• The process is very manual in nature (every change needs human review and confirmation).
• There could possibly be some form of automation to detect when they fall out of sync.
• The new concepts behind the build script changes (pages and routes) are quite novel. This took some time to adjust and learn for most to understand and get right.
• New edge cases are still being discovered, so everyone needs to be attentive and responsive to reports. Example: discontinuing the practice of pinning @wordpress npm dependencies to each release has made the package-update --dist-tag=7.0 no longer works (see the related conversation in Slack).
• While working on build tooling-related tasks is not always enjoyable, more eyes are needed to refine the changes.
• Overall, this brought the two code bases closer together and clears the way for more frequent syncing. But the speed at which each operates is still quite different.

Improving Communication

Maintainers need to put more of an emphasis on consistency and err on the side of over communicating. Announcing in progress explorations or planned changes earlier has many benefits:

• Avoids breaking contributor workflows
• Sets consistent and clear expectations (no surprises)
• Limits unconsidered edge cases
• Increases the chances for feedback
• Higher quality feedback overall
• Ensures the full context, motivations, background, and goals behind a given change are known and understood.
• Smaller gap between perceptions and realities.

The form of communication was not clear and would likely vary at different phases. It could involve RFCs (requests for change), Trac updates, weekly Dev Chat discussions, and more.

A Canary-style Approach to WordPress

A proposal was made to consider approaching WordPress development in a similar way to Chrome (using a Canary-style version with feature flags). The idea is to have the ability to work on more features at once, faster, being more proactive about requesting feedback, collect more crash telemetry, etc.
There was a healthy discussion that ultimately led to agreement that this would represent a significant shift from how Core is built and maintained today. Everything from how code is committed to how Trac/GitHub/tickets are utilized to how the project communicates what’s being worked on and what changes are upcoming would need to change. Some talking points that were discussed at length without a resolution:

• What would the difference between Core + Gutenberg plugin be from these Canary-style builds?
• How would someone decide between builds?
• How would the location be chosen for a feature (stable in wordpress-develop, experimental in gutenberg, etc.)?
• There’s currently no concept of experimental features within wordpress-develop, but there is in Gutenberg.
• When someone builds a feature on a Canary-style build and dependent code is removed or changed, that breaks.
• Should there still be a Gutenberg plugin? What if PHP was not allowed in Gutenberg and had to be committed to wordpress-develop instead?

Currently, wordpress.org seems to be the canary along with anyone else running the nightly builds. WordPress.com runs the Gutenberg plugin, which has made it much easier to update once reaching the beta release phase of a release. However, w.com is an outlier and many of the problems that are found do not typically affect more managed hosts.

More Testing More Often

It was mentioned that the problem that was being targeted is that it’s not easy to test one specific feature and the project can often receive late or inadequate levels of testing. There also can be a hesitance to merge certain features because it’s not clear what the desired level of testing is, or if that has actually been achieved.

Most of the discussion so far was acknowledged to be a technical solution to a communications problem. Canary-styled releases have also become a marketing solution for Chrome, not necessarily a “more testing” one. It could also become even more confusing for users very quickly. The conversation shifted to discussing the feedback problem.

• Far too few sites test the beta/RC versions for each release.
• It’s unknown how many sites turn on the experiments in the Gutenberg plugin. Or how many actually interact with those experiments.
• The Beta Tester plugin currently only has ~3,000 active installs, and those installs may not be configured to use non-stable releases.

Beta Testing Natively In Core

One option mentioned was to consider merging the Beta Tester plugin into Core. There was broad agreement to at least explore this idea.

• People click on things when they see them in an interface when they sound good.
• There would need to be a way to revert to a stable release in case. Though this doesn’t currently exist and is not supported. Database migrations do not work in reverse.
• Would this shoot the project in the foot by making it easier to opt-in to these development releases?
• Cleaning up old files that never actually made it into a release could be a problem.
• The risk of breaking live sites increases. This needs to be properly communicated and the project needs to be prepared to deal with these scenarios.
• Allowing someone to opt-in to beta and RC releases is a low risk good first step.
• It could be gated behind a constant in a way similar to multisite with WP_ALLOW_MULTISITE. At that point, would it be any different than

Other Shared Thoughts

• The project as a whole needs to be more clear about what type of feedback is desired (user feedback, technical feedback, etc.).
• The path for turning on experimental features has gotten pretty complex in some cases. For example, the content policies experiment in Gutenberg requires the AI plugin as well as a connector to be installed and active. Sometimes experiments also require a specific patch or pull request.
• There could possibly be a way to opt-in to all experiments that ship in the Gutenberg plugin, including any added in the future.
• It would be great to have a way to know how many sites are using each experiment.

Thoughts on Real-time Collaboration

An open floor was set for feedback about removing real-time collaboration from the WordPress 7.0 release.

• The overwhelming majority of attendees agreed with the move to revert the feature for the 7.0 release.
• There needs to be a clear list of criteria to be met before reconsidering. The reasons for removal were reasonable and real, but it’s not yet clear how to address each of those.
• Some felt that the ball was dropped telling the story behind the feature. What would it actually mean in practice to users, especially those with a single user?
• RTC could possibly enable a level of agentic AI functionality, but that is more likely to be made possible with the Notes feature.
• There needs to be a final architectural decision that the project is comfortable standing behind and supporting long term.
• Some expressed that they felt it had to go in and would no matter what because experienced names were called in to help address the shortcomings of the feature at the last minute.
• It has been unclear at times how the feature fits into the overall goals of the project.
• What does the delay of shipping RTC mean for the 4 phases of Gutenberg and the project’s current priorities?

Does The Feature Belong In Core?

A strong opinion, loosely held, was expressed and discussed: The full RTC feature set should not be in core, but the underlying architecture should be.

• There is a lot of overhead being added with very little apparent gain at the moment.
• Some of the YJS pieces and integrations must be in Core to actually work.
• What if core only shipped with the WebSockets transport, with the HTTP polling transport being the optional plugin given the scaling issues?
• The feature could be added in two parts, similar to the REST API.
• Who would maintain the parts that are merged into Core?
• This approach could result in a new flavor of WordPress hosting with support for RTC. This could be frustrating for users if they change hosts and find the feature no longer works.

Recent Changes to Committer GitHub Capabilities

One attendee mentioned that they no longer have the ability to bypass the required checks on pull requests in the Gutenberg repository (something that was previously possible). They were curious if their access had been adjusted or capabilities were adjusted. It was mentioned that there are a handful of other Committers who have reported differences in what actions they are able perform on GitHub (restarting Action workflow runs, etc.).

To the knowledge of everyone in attendance, there have been no intentional changes made to the WordPress Core team under the WordPress organization (which includes all Core Committers). It’s possible that something has changed on the GitHub side.

@desrosj and @johnbillion will investigate this and follow up in #core-committers.

Process Reminder for Assigning Commit-level Access

The group was reminded that since the bulk adjustment was made to sync the two groups in 2024, being a Core SVN committer is a requirement for being included in the Gutenberg Core team on GitHub. While this team is a subset of Core Committers, this must be followed for consistency in committer-level access across the two code bases and reinforcing the fact that “Core = Gutenberg, Gutenberg = Core”.

The team’s description on GitHub will be updated to reference this policy to make it harder to forget. The Core Handbook and documentation within the Gutenberg repository will be updated as well.

Summary

Attendees shared at the end that the meeting was very helpful for everyone to get on the same page. It was suggested that more frequent meetings (a mix of both virtual and in-person) for the group would be very beneficial.

Action Items

• Address differences between svn:ignore properties and .gitignore rules through #64971.
• Continue testing and iterating on the new build processes introduced during 7.0 and consider ways to improve these scripts further.
• Be more communicative about any work being done/changes being considered, why they’re important, and the honest state of the efforts.
• Think of ways to increase testing of every upcoming WordPress release. Follow up with proposals for suggested changes publicly.
• Think of new ways to create and strengthen feedback loops to increase confidence in specific changes.
• Seek clarity on the next steps and new acceptance criteria for Real-time Collaboration.
• Investigate recent changes to the committer-level access on GitHub.
• Consider ways for Core Committers to sync more frequently.

Props @dmsnell, @westonruter, @johnbillion for pre-publish review.

#core-committer-meetings, #core-committers