{"id":123829,"date":"2026-06-15T13:54:16","date_gmt":"2026-06-15T13:54:16","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=123829"},"modified":"2026-06-17T17:23:00","modified_gmt":"2026-06-17T17:23:00","slug":"core-committers-meeting-wordcamp-europe-2026","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/06\/15\/core-committers-meeting-wordcamp-europe-2026\/","title":{"rendered":"Core Committers Meeting &#8211; WordCamp Europe 2026"},"content":{"rendered":"<p class=\"wp-block-paragraph\">On June 5, 2026, <span tabindex='0' class='glossary-item-container'>Core<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Core<\/span> <span class='glossary-item-description'>Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span> Committers in attendance (including emeritus) at <a href=\"https:\/\/europe.wordcamp.org\/2026\/\">WordCamp Europe in Krak\u00f3w, Poland<\/a> gathered for a brief informal meeting.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-scaled.jpg\"><img loading=\"lazy\" decoding=\"async\" width=\"2560\" height=\"1380\" data-attachment-id=\"123835\" data-permalink=\"https:\/\/make.wordpress.org\/core\/2026\/06\/15\/core-committers-meeting-wordcamp-europe-2026\/wceu-core-committers-meeting\/#main\" data-orig-file=\"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-scaled.jpg\" data-orig-size=\"2560,1380\" data-comments-opened=\"1\" data-image-meta='{\"aperture\":\"1.78\",\"credit\":\"\",\"camera\":\"iPhone 17 Pro Max\",\"caption\":\"\",\"created_timestamp\":\"1780597283\",\"copyright\":\"\",\"focal_length\":\"6.7649998656528\",\"iso\":\"320\",\"shutter_speed\":\"0.02\",\"title\":\"\",\"orientation\":\"1\",\"alt\":\"\"}' data-image-title=\"WCEU Core Committers Meeting\" data-image-description=\"\" data-image-caption=\"\" data-large-file=\"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-1024x552.jpg\" src=\"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-scaled.jpg\" alt=\"The WordPress Core Committers posing on stage at WordCamp Europe 2026 after meeting.\" class=\"wp-image-123835\" srcset=\"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-scaled.jpg 2560w, https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-300x162.jpg 300w, https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-1024x552.jpg 1024w, https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-768x414.jpg 768w, https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-1536x828.jpg 1536w, https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-edited-2048x1104.jpg 2048w\" sizes=\"auto, (max-width: 2560px) 100vw, 2560px\"><\/a><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">There was no formal agenda, but a few goals for the meeting were mentioned at the beginning:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allow newer committers to meet more senior ones.<\/li>\n\n\n\n<li>Allow anyone to raise questions, concerns, or suggestions that have been on their minds.<\/li>\n\n\n\n<li>Just spend some time together chatting and getting to know each other.<\/li>\n\n\n\n<li>Discuss short and medium term challenges.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Below are some brief notes from discussions that happened following<a href=\"https:\/\/en.wikipedia.org\/wiki\/Chatham_House_Rule\"> Chatham House Rule<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Reducing Friction Between Code Bases<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The meeting started by discussing the recent changes to the build scripts in both <code>wordpress-develop<\/code> and <code>gutenberg<\/code> aimed at making it easier to sync the changes from <code>gutenberg<\/code> on <span tabindex='0' class='glossary-item-container'>GitHub<span class='glossary-item-hidden-content'><span class='glossary-item-header'>GitHub<\/span> <span class='glossary-item-description'>GitHub 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 \u2018pull request\u2019 where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. <a href=\"https:\/\/github.com\/\">https:\/\/github.com\/<\/a><\/span><\/span><\/span> into <code>wordpress-develop<\/code> in <span tabindex='0' class='glossary-item-container'>SVN<span class='glossary-item-hidden-content'><span class='glossary-item-header'>SVN<\/span> <span class='glossary-item-description'>Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.<\/span><\/span><\/span>.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>It was painful at first, but the most disruptive initial issues have been addressed.<\/li>\n\n\n\n<li>The <code>svn:ignore<\/code> properties are still out of sync with the changes made to <code>.gitignore<\/code>.<\/li>\n\n\n\n<li><a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64971\">#64971<\/a> is open to address this.<\/li>\n\n\n\n<li>This is very easy to miss due to differences between SVN and <span tabindex='0' class='glossary-item-container'>Git<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Git<\/span> <span class='glossary-item-description'>Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system.\r<a href=\"https:\/\/git-scm.com\/\">https:\/\/git-scm.com\/<\/a><\/span><\/span><\/span>.<\/li>\n\n\n\n<li>This process should be a reoccurring task.<\/li>\n\n\n\n<li>The process is very manual in nature (every change needs human review and confirmation).<\/li>\n\n\n\n<li>There could possibly be some form of automation to detect when they fall out of sync.<\/li>\n\n\n\n<li>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.<\/li>\n\n\n\n<li>New edge cases are still being discovered, so everyone needs to be attentive and responsive to reports. Example: discontinuing the practice of pinning <code>@wordpress<\/code> npm dependencies to each release has made the <code>package-update --dist-tag=7.0<\/code> no longer works (see the related <a href=\"https:\/\/wordpress.slack.com\/archives\/C02QB2JS7\/p1780497426045309\">conversation in Slack<\/a>).<\/li>\n\n\n\n<li>While working on build tooling-related tasks is not always enjoyable, more eyes are needed to refine the changes.<\/li>\n\n\n\n<li>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.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Improving Communication<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoids breaking contributor workflows<\/li>\n\n\n\n<li>Sets consistent and clear expectations (no surprises)<\/li>\n\n\n\n<li>Limits unconsidered edge cases<\/li>\n\n\n\n<li>Increases the chances for feedback<\/li>\n\n\n\n<li>Higher quality feedback overall<\/li>\n\n\n\n<li>Ensures the full context, motivations, background, and goals behind a given change are known and understood.<\/li>\n\n\n\n<li>Smaller gap between perceptions and realities.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The form of communication was not clear and would likely vary at different phases. It could involve RFCs (requests for change), <span tabindex='0' class='glossary-item-container'>Trac<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Trac<\/span> <span class='glossary-item-description'>An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.<\/span><\/span><\/span> updates, weekly Dev Chat discussions, and more.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A Canary-style Approach to WordPress<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A proposal was made to consider approaching WordPress development in a similar way to Chrome (using a Canary-style version with <a href=\"https:\/\/developer.chrome.com\/docs\/web-platform\/chrome-flags\/\">feature flags<\/a>). 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.<br>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\u2019s being worked on and what changes are upcoming would need to change. Some talking points that were discussed at length without a resolution:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What would the difference between Core + <span tabindex='0' class='glossary-item-container'>Gutenberg<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Gutenberg<\/span> <span class='glossary-item-description'>The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.\r<a href=\"https:\/\/wordpress.org\/gutenberg\/\">https:\/\/wordpress.org\/gutenberg\/<\/a><\/span><\/span><\/span> <span tabindex='0' class='glossary-item-container'>plugin<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Plugin<\/span> <span class='glossary-item-description'>A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory <a href=\"https:\/\/wordpress.org\/plugins\/\">https:\/\/wordpress.org\/plugins\/<\/a> or can be cost-based plugin from a third-party.<\/span><\/span><\/span> be from these Canary-style builds?<\/li>\n\n\n\n<li>How would someone decide between builds?<\/li>\n\n\n\n<li>How would the location be chosen for a feature (stable in <code>wordpress-develop<\/code>, experimental in <code>gutenberg<\/code>, etc.)?<\/li>\n\n\n\n<li>There\u2019s currently no concept of experimental features within <code>wordpress-develop<\/code>, but there is in Gutenberg.<\/li>\n\n\n\n<li>When someone builds a feature on a Canary-style build and dependent code is removed or changed, that breaks.<\/li>\n\n\n\n<li>Should there still be a Gutenberg plugin? What if <span tabindex='0' class='glossary-item-container'>PHP<span class='glossary-item-hidden-content'><span class='glossary-item-header'>PHP<\/span> <span class='glossary-item-description'>The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher<\/span><\/span><\/span> was not allowed in Gutenberg and had to be committed to <code>wordpress-develop<\/code> instead?<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Currently, <a href=\"http:\/\/wordpress.org\">wordpress.org<\/a> seems to be the canary along with anyone else running the nightly builds. <a href=\"http:\/\/wordpress.com\">WordPress.com<\/a> runs the Gutenberg plugin, which has made it much easier to update once reaching the <span tabindex='0' class='glossary-item-container'>beta<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Beta<\/span> <span class='glossary-item-description'>A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.<\/span><\/span><\/span> release phase of a release. However, <a href=\"http:\/\/w.com\">w.com<\/a> is an outlier and many of the problems that are found do not typically affect more managed hosts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">More Testing More Often<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It was mentioned that the problem that was being targeted is that it\u2019s 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\u2019s not clear what the desired level of testing is, or if that has actually been achieved.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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 \u201cmore testing\u201d one. It could also become even more confusing for users very quickly. The conversation shifted to discussing the feedback problem.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Far too few sites test the beta\/<span tabindex='0' class='glossary-item-container'>RC<span class='glossary-item-hidden-content'><span class='glossary-item-header'>release candidate<\/span> <span class='glossary-item-description'>One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see <a href=\"#alpha-beta\">alpha (beta)<\/a>.<\/span><\/span><\/span> versions for each release.<\/li>\n\n\n\n<li>It\u2019s unknown how many sites turn on the experiments in the Gutenberg plugin. Or how many actually interact with those experiments.<\/li>\n\n\n\n<li>The Beta Tester plugin currently only has ~3,000 active installs, and those installs may not be configured to use non-stable releases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Beta Testing Natively In Core<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">One option mentioned was to consider merging the Beta Tester plugin into Core. There was broad agreement to at least explore this idea.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>People click on things when they see them in an interface when they sound good.<\/li>\n\n\n\n<li>There would need to be a way to revert to a stable release in case. Though this doesn\u2019t currently exist and is not supported. Database migrations do not work in reverse.<\/li>\n\n\n\n<li>Would this shoot the project in the foot by making it easier to opt-in to these development releases?<\/li>\n\n\n\n<li>Cleaning up old files that never actually made it into a release could be a problem.<\/li>\n\n\n\n<li>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.<\/li>\n\n\n\n<li>Allowing someone to opt-in to beta and RC releases is a low risk good first step.<\/li>\n\n\n\n<li>It could be gated behind a constant in a way similar to <span tabindex='0' class='glossary-item-container'>multisite<span class='glossary-item-hidden-content'><span class='glossary-item-header'>multisite<\/span> <span class='glossary-item-description'>Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also <strong>network<\/strong>, <strong>blog<\/strong>, <strong>site<\/strong><\/span><\/span><\/span> with <code>WP_ALLOW_MULTISITE<\/code>. At that point, would it be any different than\u00a0testing features in Gutenberg or a <span tabindex='0' class='glossary-item-container'>feature plugin<span class='glossary-item-hidden-content'><span class='glossary-item-header'>Feature Plugin<\/span> <span class='glossary-item-description'>A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See <a href=\"https:\/\/make.wordpress.org\/core\/handbook\/about\/release-cycle\/features-as-plugins\/\">Features as Plugins<\/a><\/span><\/span><\/span>?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Other Shared Thoughts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The project as a whole needs to be more clear about what type of feedback is desired (user feedback, technical feedback, etc.).<\/li>\n\n\n\n<li>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 <span tabindex='0' class='glossary-item-container'>patch<span class='glossary-item-hidden-content'><span class='glossary-item-header'>patch<\/span> <span class='glossary-item-description'>A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a <strong>diff<\/strong>. A patch can be <em>applied<\/em> to a codebase for testing.<\/span><\/span><\/span> or pull request.<\/li>\n\n\n\n<li>There could possibly be a way to opt-in to all experiments that ship in the Gutenberg plugin, including any added in the future.<\/li>\n\n\n\n<li>It would be great to have a way to know how many sites are using each experiment.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Thoughts on Real-time Collaboration<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An open floor was set for feedback about removing real-time collaboration from the WordPress 7.0 release.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The overwhelming majority of attendees agreed with the move to revert the feature for the 7.0 release.<\/li>\n\n\n\n<li>There needs to be a clear list of criteria to be met before reconsidering. The reasons for removal were reasonable and real, but it\u2019s not yet clear how to address each of those.<\/li>\n\n\n\n<li>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?<\/li>\n\n\n\n<li>RTC could possibly enable a level of agentic AI functionality, but that is more likely to be made possible with the Notes feature.<\/li>\n\n\n\n<li>There needs to be a final architectural decision that the project is comfortable standing behind and supporting long term.<\/li>\n\n\n\n<li>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.<\/li>\n\n\n\n<li>It has been unclear at times how the feature fits into the overall goals of the project.<\/li>\n\n\n\n<li>What does the delay of shipping RTC mean for the 4 phases of Gutenberg and the project\u2019s current priorities?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Does The Feature Belong In Core?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>There is a lot of overhead being added with very little apparent gain at the moment.<\/li>\n\n\n\n<li>Some of the YJS pieces and integrations must be in Core to actually work.<\/li>\n\n\n\n<li>What if core only shipped with the WebSockets transport, with the <span tabindex='0' class='glossary-item-container'>HTTP<span class='glossary-item-hidden-content'><span class='glossary-item-header'>HTTP<\/span> <span class='glossary-item-description'>HTTP is an acronym for Hyper Text Transfer Protocol. HTTP  is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.<\/span><\/span><\/span> polling transport being the optional plugin given the scaling issues?<\/li>\n\n\n\n<li>The feature could be added in two parts, similar to the <span tabindex='0' class='glossary-item-container'>REST API<span class='glossary-item-hidden-content'><span class='glossary-item-header'>REST API<\/span> <span class='glossary-item-description'>The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think \u201cphone app\u201d or \u201cwebsite\u201d) can communicate with the data store (think \u201cdatabase\u201d or \u201cfile system\u201d)\r<a href=\"https:\/\/developer.wordpress.org\/rest-api\/\">https:\/\/developer.wordpress.org\/rest-api\/<\/a><\/span><\/span><\/span>.<\/li>\n\n\n\n<li>Who would maintain the parts that are merged into Core?<\/li>\n\n\n\n<li>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.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Recent Changes to <span tabindex='0' class='glossary-item-container'>Committer<span class='glossary-item-hidden-content'><span class='glossary-item-header'>committer<\/span> <span class='glossary-item-description'>A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and\/or for a specific component.<\/span><\/span><\/span> GitHub <span tabindex='0' class='glossary-item-container'>Capabilities<span class='glossary-item-hidden-content'><span class='glossary-item-header'>capability<\/span> <span class='glossary-item-description'>A\u00a0<strong>capability<\/strong>\u00a0is permission to perform one or more types of task. Checking if a user has a capability is performed by the <code>current_user_can<\/code> function. Each user of a WordPress site might have some permissions but not others, depending on their\u00a0role. For example, users who have the Author role usually have permission to edit their own posts (the \u201cedit_posts\u201d capability), but not permission to edit other users\u2019 posts (the \u201cedit_others_posts\u201d capability).<\/span><\/span><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">To the knowledge of everyone in attendance, there have been no intentional changes made to the <a href=\"https:\/\/github.com\/orgs\/WordPress\/teams\/wordpress-core\">WordPress Core team<\/a> under the WordPress organization (which includes all Core Committers). It\u2019s possible that something has changed on the GitHub side.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/profiles.wordpress.org\/desrosj\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>desrosj<\/a> and <a href=\"https:\/\/profiles.wordpress.org\/johnbillion\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>johnbillion<\/a> will investigate this and follow up in <a href=\"https:\/\/wordpress.slack.com\/archives\/C18723MQ8\">#core-committers<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Process Reminder for Assigning Commit-level Access<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The group was reminded that since the <a href=\"https:\/\/make.wordpress.org\/core\/2024\/07\/22\/aligning-committer-level-access-across-the-code-base\/\">bulk adjustment was made to sync the two groups in 2024<\/a>, being a Core SVN committer is a requirement for being included in the <a href=\"https:\/\/github.com\/orgs\/WordPress\/teams\/gutenberg-core\">Gutenberg Core team<\/a> 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 \u201cCore = Gutenberg, Gutenberg = Core\u201d.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The team\u2019s 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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Action Items<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Address differences between <code>svn:ignore<\/code> properties and <code>.gitignore<\/code> rules through <a href=\"https:\/\/core.trac.wordpress.org\/ticket\/64971\">#64971<\/a>.<\/li>\n\n\n\n<li>Continue testing and iterating on the new build processes introduced during 7.0 and consider ways to improve these scripts further.<\/li>\n\n\n\n<li>Be more communicative about any work being done\/changes being considered, why they\u2019re important, and the honest state of the efforts.<\/li>\n\n\n\n<li>Think of ways to increase testing of every upcoming WordPress release. Follow up with proposals for suggested changes publicly.<\/li>\n\n\n\n<li>Think of new ways to create and strengthen feedback loops to increase confidence in specific changes.<\/li>\n\n\n\n<li>Seek clarity on the next steps and new acceptance criteria for Real-time Collaboration.<\/li>\n\n\n\n<li>Investigate recent changes to the committer-level access on GitHub.<\/li>\n\n\n\n<li>Consider ways for Core Committers to sync more frequently.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-right wp-block-paragraph\"><em>Props <a href=\"https:\/\/profiles.wordpress.org\/dmsnell\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>dmsnell<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/westonruter\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>westonruter<\/a>, <a href=\"https:\/\/profiles.wordpress.org\/johnbillion\/\" class=\"mention\"><span class=\"mentions-prefix\">@<\/span>johnbillion<\/a> for pre-publish review.<\/em><\/p>\n<p class=\"o2-appended-tags\"><a href=\"https:\/\/make.wordpress.org\/core\/tag\/core-committer-meetings\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>core-committer-meetings<\/a>, <a href=\"https:\/\/make.wordpress.org\/core\/tag\/core-committers\/\" class=\"tag\"><span class=\"tag-prefix\">#<\/span>core-committers<\/a><\/p><nav class='o2-post-footer-actions'><ul class='o2-post-footer-action-row'><li class='o2-post-footer-action'><a href=\"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2026%2F06%2F15%2Fcore-committers-meeting-wordcamp-europe-2026%2F%23respond&#038;locale=en_US\" title=\"Login to Reply\"  class=\"genericon  genericon-reply\"  data-action=\"login-to-reply\"  data-actionstate=\"default\" >Login to Reply<\/a><\/li><\/ul><div class='o2-post-footer-action-likes'><\/div><ul class='o2-post-footer-action-row'><\/ul><\/nav>","protected":false},"excerpt":{"rendered":"<p>On June 5, 2026, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) at WordCamp Europe in Krak\u00f3w, Poland gathered for a brief informal meeting. There was no formal agenda, but a few goals for the meeting were mentioned at the beginning: [&hellip;]<\/p>\n","protected":false},"author":4552240,"featured_media":123833,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[1173],"tags":[5726,5046],"class_list":["post-123829","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-meetings","tag-core-committer-meetings","tag-core-committers","mentions-desrosj","mentions-dmsnell","mentions-johnbillion","mentions-westonruter","author-desrosj"],"revision_note":"","jetpack_featured_media_url":"https:\/\/make.wordpress.org\/core\/files\/2026\/06\/IMG_4415-scaled.jpg","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2AvED-wdf","_links":{"self":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/123829","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/users\/4552240"}],"replies":[{"embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/comments?post=123829"}],"version-history":[{"count":5,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/123829\/revisions"}],"predecessor-version":[{"id":123944,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/posts\/123829\/revisions\/123944"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/media\/123833"}],"wp:attachment":[{"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/media?parent=123829"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/categories?post=123829"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/make.wordpress.org\/core\/wp-json\/wp\/v2\/tags?post=123829"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}