Core Committer Meeting notes from WordCamp US 2025

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US 2025, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) gathered for a brief informal meeting. A few additional contributors with a heavy focus on Core were also invited.

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

  • 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.

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

Attendees: @marybaum, @aaroncampbell, @adamsilverstein, @nerrad, @flixos90, @jeffpaul, @davidbaumwald, @whyisjake@jjj, @ryelle, @dmsnell, @ellatrix, @matt, @bpayton, @karmatosed, @westonruter, @helen, @priethor, @kadamwhite, @joemcgill, @timothyblynjacobs, @annezazu, @jorbin

Getting New Contributors and Committers

The first topic raised was that the majority of committers are long term contributors and in order to ensure the health of the project, it is necessary ensure new contributors are rising up and taking on additional responsibilities. 

It was noted that multiple contributors had a good experience with Google Summer of Code (GSoC) both as mentors and participants. WordPress hasn’t participated for a few years since there is a burden to organzing it. However, this group felt that it is worth re-evaluating and may be worth participating again in 2026.

Mentorship is also very important in helping new contributors take on additional responsibilities, though this mentorship can feel like a lot of work and is often hidden work. It’s hard to show a measurable ROI. Using learn.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ to share process was identified as one way to scale mentorship. Instead of being 1:1, it can be 1:many. Additionally, using cohorts allows more contributors to benefit from mentorship.

It was also pointed out that there is an excitement about contributing that can be contagious. It’s important to get people excited about solving problems since seeing people excited can make more people excited. It’s also important to make space for more contributors and remember that taking a step back for newer contributors to pick up those responsibilities doesn’t need to mean taking a step out.

WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. in Core. 

It was highlighted that at times the current WPCSWordPress Community Support A public benefit corporation and a subsidiary of the WordPress Foundation, established in 2016. can be a challenge rather than actually helpful. Some current rules are outdated and may not be as helpful as they were thought to be when originally added to WordPress. Additionally, all the ignores that these inspire leads to Core code feeling odd. These rules include (but are not limited to):

  • Yoda Conditionals (Not viewed as necessary since we don’t allow assignment in conditionals)
  • ZigZag alignment from aligning equal signs (Can lead to needing to change multiple unaffected lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses.)
  • Pre-increment (Added based on a comment on php.net that doesn’t appear to be accurate)

The goal of coding standards is to make it easier to contribute. If individuals are finding it hard to conform to the existing rules, contributors are encouraged to ask for help in slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

As it has been seven years since WordPress adopted coding standards, the recommendation from the group is to do a full audit of all the existing rules and then adjust the existing code to follow this new recommendation.

It was also suggested that the WPCS run on Pull Requests could be manually run instead of automatically enqueued so that new contributors aren’t immediately met with rejections.

How to make decisions when there is no clear decider

It’s often unclear who has the ability to make a specific decision and this can lead to bike shedding and/or an impasse. Several factors contribute to the decision-making paralysis. Committers often fear closing tickets that many people want, even if consensus among committers is that the functionality isn’t appropriate for core. The expansion of release squads from small, experienced teams to larger groups with varying experience levels has diluted clear ownership and decision-making authority.

One option to solve this that was discussed is to start using PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher RFC style voting amongst committers. It was also mentioned that if people are feeling like getting to a decision is difficult, or if someone is not fully confident in a decision, bringing attention to the topic in dev-chat or the #core slack channel can be helpful to gaining additional confidence. 

Committers also reminded each other to give folks grace if they make a mistake. If a decision turns out to not be correct, we should empower people to speak up when they see negative impacts, and then work to fix or revert. However, it remains important to choose a direction, support it as a team, and adapt if the outcomes aren’t right.

Communication channels like slack, quarterly calls, and Hallway Hangouts were highlighted as valuable spaces for building trust and confidence in our decisions.

LLM Attribution and “AI Slop”

We are starting to see challenges with “AI Slop,” where contributions arrive as very large PRs that are difficult to review effectively. When this happens, contributors are encouraged to step back and discuss the underlying problem before moving ahead with code. In cases where a PR includes too many changes at once, it’s also reasonable to ask for the work to be split into smaller, more focused PRs to make review more manageable. And as always, there’s no expectation that every PR be reviewed, particularly when the work doesn’t align with agreed-upon priorities.

Props to @dmsnell and @jeffpaul for prepublication review and @jeffpaul and @jorbin for note-taking during the meeting.

#core-committer-meetings, #core-committers, #meeting

WCEU 2025 Core Committers Meeting Notes

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe last week, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) gathered for a brief informal meeting.

Photo credit: Levente András Tóth

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.

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

6.9 Release Cycle

The current major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. cycle was discussed for a bit. More specifically, what should the targeted features be? With (more) recent changes to contributor availability, it’s possible there could be a 6.9 this calendar year (was later confirmed as the goal by Matt in the fireside chat).

A new or revised short-term roadmap would help committers and contributors alike participate more effectively by providing clarity on the current focus areas, goals, and targeted features. For the long-term, clarity on whether the 4 phases are still accurate objectives.

6.8.x Releases

These should continue to be planned and executed as necessary. If major releases are going to be less frequent, carefully including smaller features and enhancements in minor versions would be beneficial.

If the timeline for the next major release does change, minor releases may not have as many contributor resources. That needs to be watched to ensure continued success of minor releases.

Possible Short-Term Targets 

A handful of possible short-term features and tasks were identified to explore:

  • address technical debt
    • there are many areas of the code base that can likely be moved from Core to a canonical pluginPlugin 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 https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. For example, the Links/Bookmarks APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
    • No-op or remove severely outdated classes deprecated long ago (3.0 times). For example, Snoopy. 
  • Perform ticketticket Created for both bug reports and feature development on the bug tracker. triaging without being afraid to say “no” more often.
  • Discuss what role themes have in present day WordPress.
    • Should we continue creating default themes going forward?
    • What do we want  as a project from blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes?
    • How does the pattern directory, font library, block plugins, etc. replace traditional theme components?
  • Audit the importer plugins.
    • Can we possibly archive repositories for importers for services long decommissioned?
    • Should we mark the importers as canonical plugins?
  • Better contextual integration points for canonical plugins (suggest installing to the user when performing related actions)
  • How can we better collect feedback from users that choose to install canonical plugins?

Bring Back User Testing

Previously, the project conducted user testing. That seems to have stopped, but this practice was very beneficial and informative. It showed how the software is actually used by users and whether the intended experience was achieved.

It would be great to resume this practice. However, users are goal oriented, not feature oriented. The outcome of user testing is usually not fine grained tickets for small, specific things. This requires different skill sets to address findings (foundational problems in experience vs. bugs to fix).

Increased Amount and Quality of Testing

If releases are spaced out more (ie. once per year), testing early and often is more important to avoid a large number of bugs down the home stretch of a release cycle.

There were questions around whether we were doing a good job encouraging the right types of quality testing.

  • the testing during release parties can likely be covered more effectively by E2E tests. Contributors are performing the same actions and not truly testing the features that are being shipped.
  • This allows for better testing actual features with specific interactions.
  • The ideal testing could be detailed prior to the release party.
  • When developer notes are published, they could include specific testing instructions.
  • A specific dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. outlining the different testing paths and intended outcomes could also be published to the Make Test blogblog (versus network, site).
  • Testing during release parties is a great way to get started contributing, but it’s gotten to a point where that testing is not a good use of resources. Too many people doing the same shallow testing at once. 
  • Can the betaBeta 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. testing plugin contextually bring in testing instructions?
  • Can the beta testing plugin better engage the user. Some inspiration can be taken from Apple’s Testflight.

Next Meeting

It’s time to schedule the next virtual Core Committercommitter 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. meeting on Zoom. The date and time of this will be coordinated in the #core-committers channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

Props @johnbillion, @flixos90 for pre-publish review.

#core-committer-meetings, #core-committers

Dotorg Core Committers Check In

On March 27, 2025 nearly 30 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers, project leaders, and core team members gathered to discuss the release cadence and if there is a need to change it. The impetus for this conversation is due to organizations cutting back on the number of hours they are donating towards contributing to WordPress.

Attendees: @matt, @desrosj, @jorbin, @timothyblynjacobs, @davidbaumwald, @jjj, @clorith, @jeffpaul, @joemcgill, @kadamwhite, @fabiankaegy, @4thhubbard, @adamsilverstein, @swissspidy, @whyisjake, @spacedmonkey, @eidolonnight, @matveb, @audrasjb, @mamaduka, @karmatosed, @sergeybiryukov, @westonruter, @ryelle, @flixos90, @williampatton, @poena, @johnbillion, @joedolson.

An assessment of core team activity shows the number of both GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ tickets and Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets remaining nearly flat over the last 6 months. However, the volume of new features being worked on inside the Gutenberg repository has plunged since January. In light of this information, the discussion focused on if the current release cadence should be reduced.

Numerous pros and cons were discussed.

The pros included:

  • Aligns WordPress with the release cadence that is becoming en vogue amongst some large organizations such as eBay and Airbnb
  • Can use this change to signal an intentional reset and focus on quality
  • Allows for greater focus on canonical plugins and on individual component roadmaps, which can be iterated on and shipped independent of major releases.
  • Slowing down helps allow for documentation and any needed infrastructure improvements.
  • Allow for each release to contain larger features and enhancements and not be “bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fix only” releases.
  • Reduces the workload and coordination overhead for contributors, systems team, and release leads.
  • Allows for work to further automate release processes, making future releases quicker and less manual.

The cons and risks discussed included:

  • Fewer releases can slow down user feedback loops for new features.
  • Slower cadence can lead to contributors not being able to see their work published or feel recognized as quickly.
  • Makes it harder for changes that we may want to roll out over multiple releases
  • Harder to make changes such as coding standard updates that can lead to a release branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". and trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. changing.
  • Potential for anxiety over larger releases from users, site owners, and anyone else applying updates.
  • Potentially harder for organizations to justify time and resources for sponsored contributors.
  • Less visible momentum towards the project’s overall goals, possibly perceiving the project as stale.
  • Care needs to be taken to preserve the culture and trust built in auto-updates that the project has worked hard to build over the last decade.

Proposed Focus Areas

The conversation moved to discussing where contributors could effectively focus their efforts in the project should the release schedule shift to just one release per year.

Canonical Plugins

Community maintained canonical plugins such as Preferred languages, 2FA, and the Performance Team’s suite of plugins are a great way to ship features and iterate without requiring a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress itself. There were two main improvements that need to be addressed to make them more effective.

First is the need for better means to collect user feedback. Active installs is currently the only metric available, but doesn’t provide enough value. Does a user actually interact with the feature? In what ways? Do they feel it’s valuable? Feedback is mainly received from users when something breaks. There was agreement to explore telemetry and ways to establish meaningful feedback loops within canonical plugins.

The second improvement needed is promotion. It’s often not widely known that canonical plugins exist or that they are officially maintained. Different ways to raise awareness about canonical plugins will be explored, including posts on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ News blogblog (versus network, site), mentioning them in presentations such as State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/., and possibly the currently barren Tools page in the WordPress adminadmin (and super admin).

Backlog Management

  • Going through the backlog of ~13,000 total tickets on Trac and Gutenberg’s GitHubGitHub 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 ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository is something that can be done independent of major releases.
  • The majority of bugfixes can be shipped in minor releases.
  • maybelater' resolution exists for a reason and should be used more often. Discussion can always continue on closed tickets.
  • A large backlog can damage the perception of project quality and maintainability.
  • All numbers are just numbers in isolation. They need to be considered in context with surrounding factors.

Miscellaneous

  • Look for ways to encourage wider testing of betaBeta 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./RCrelease candidate 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 alpha (beta). releases, and even nightly builds through the initiatives like the Host Tests, and educating developers of the possible advantages of continually using trunk for testing.
  • Reevaluate the Core SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase./Gutenberg repository setup to find ways to streamline the release process.
  • With overall fewer features being built in the Gutenberg repository, shifting the pluginPlugin 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 https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’s release cadence to once a month may make sense. Though the current cadence is manageable, mostly automated, keeping this consistent is preferable if volume allows.
  • Encourage component maintainers to be more active by clarifying the responsibilities and expectations of volunteering in that capacity.
  • Release squads should primarily coordinate, encouraging broader autonomy and participation by components and various Make WordPress teams.
  • For accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), clarify the differences between mandatory compliance (WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.) and what non-blocking aspirational best practices are.
  • Explore faster release models once shortcomings in tooling are addressed.
  • Get better at involving contributors with non-development skill sets (e.g., design, testing, product) in more ways.

Summary

In light of these discussions, the current plans of project leadership are for 6.8 (due this month) to be the final major release of 2025. Gutenberg releases will continue on the current every two week schedule and minor releases will take place as needed throughout the year. Minor releases will continue and happen as necessary with a more relaxed barrier for inclusion of enhancements, but the “no new files in minor releases” rule should continue to be followed.

Based on this productive conversation, a decision was made to organize these calls on an ongoing basis starting with a quarterly cadence. I will ensure to schedule accordingly.

Props to @jorbin and @desrosj for collecting the summary and writing this post.

#core-committer-meetings, #core-committers

WordCamp Asia 2025 Core Committer Meeting Notes

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) gathered for a brief informal meeting. A few additional contributors with a heavy focus on GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ were also invited.

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.

Short Term Concerns

The first topic raised was around how to ensure Core development continues over the next 3-6 months given recent changes to contributor availability. Roughly grouped, here are some points that were raised.

  • Gutenberg is very product focused. There needs to be clarity around how to receive product-based feedback.
  • There are many ongoing projects within the editor that now have no clear owner or someone with enough knowledge to continue working on.
  • There is a roadmap of the high-level view, but there needs to be a short-term one so contributors know where to focus their efforts.
  • It would be best to narrow it down to a smaller list of “projects” to focus attention.
  • Pick smaller sets of goals for next two releases.
  • Can be frustrating to work on something that stagnates. How can we avoid that?
  • Those looking to step up and contribute more don’t know where to focus their efforts.
  • Having 6.9 and possibly 7.0 focus on maintenance could be very beneficial.
  • There is a bottle neck with experienced mentors. We need to prevent burn out with the handful left.
  • The same mentors are also heavily involved in reviewing PRs (which is another bottle neck).
  • There needs to be clarity around what we accept in general.
    • What are the requirements for adding new blocks?
    • How do we accept new blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. variations, etc.
    • A handbook page similar to the oEmbed guidelines would be beneficial.
  • Walking the fine line of being locked into backwards compatibility vs. the ability to iterate on the product (improving extensibility and adding features vs. making it harder to maintain long term)
  • A more complete design system would make it easier to guide decisions.
  • Some possible short term projects:
    • cleaning up the back log/general maintenance
    • extensibility
    • low hanging fruit/clean up issues
    • font library support in classic themes
    • feature parity in classic themes
  • How do we make decisions with fewer visionary/product focused contributor hours available?

Making it easier to contribute

In order to better stabilize the contributor base, it needs to become easier to get involved contributing to the project. It’s generally intimidating and difficult to know where to get started, where you are needed, where you can be most effective.

  • There may have been a lapse following the most recent contributor mentorship group. Some were not sure how or where to continue.
  • Need to bring newer contributors into areas where they can be the most productive and effective.
  • More clearly defined projects could lend to that.
  • Cleaning up the backlog and open PRs could also help make this more clear.
  • Changes to contributor availability could make it easier to get involved in some ways.
  • There are companies interested in investing resources for contributing through 5FTF. Clarity helps them know where the most effective places are.
  • Five for the Future often supports more senior contributors (net neutral). How can we encourage companies to also invest in contributors who are not currently sponsored at all?

Areas Requiring Clarity

  • It’s not always clear when committers are trusted or allowed to merge certain changes. Who needs to sign off on what?
    • In general, committers are trusted to use their best judgement when committing. If they feel confident in a change but are unable to get additional feedback after reasonable attempts, they should feel empowered to try a change. It can always be refined or reverted.
    • Need to do better instilling this when on boarding.
  • It’s not clear who is available to review overlapping changes from the editor. For example, the REST APIREST API 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 “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. or widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. components.
  • It’s not clear which contributors are currently available to provide feedback on pull requests given recent changes to available contribution time.
    • In general, don’t be afraid to pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” anyone who appears to have stepped back from contributing. At a minimum, they should respond with a recommendation of who to follow up with. At a maximum, a surface level review of the idea and approach.
    • git blame can also be used to make educated guesses about who to ask for feedback.
  • The Code Owners file is confusing.
    • It’s generally used by contributors to “subscribe” to be notified when areas of the code base are changed.
    • The community perceives code owners as maintainers of the defined areas.
    • The fact that GitHubGitHub 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 ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ assigns those contributors as reviewers makes this worse.
  • The components in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and teams/feature labels in Gutengberg repository don’t align.
    • Editor component is a bucket for everything from Gutenberg repository.
    • Improving this organization is important, but seeking maintainers for areas outside of the more narrow focuses is not a good idea while spread thin.

Follow up action items

  • Identify the projects/features to focus on in the short term.
  • Perform the regular component maintainer audit to make it more clear who is actively maintaining areas of the code base.
  • Audit the contributor groups and members of those groups on the Gutenberg repository. Should these reflect the same expectations as Core Component Maintainers? Can these make it more clear who should be asked/is available for feedback/reviews?
  • Remove the code owners file in the Gutenberg repository to avoid confusion around who is required to sign off on changes to areas of the code base.
    • Explore different ways that contributors can “subscribe” to parts of the Gutenberg repository.
  • Draft a proposal for how the code owners file should be utilized in the future to avoid this confusion if the file is reintroduced. It should indicate someone is an active maintainer of those files, and owners should commit to actively reviewing related pull requests.
  • Propose an update to the pull request template file explaining the expectation around reviews and who is responsible.
  • Improve documentation on labels, teams, processes, etc. in Gutenberg handbook.
  • How can we make committers feel more empowered to make decisions?
  • Connect with the Contributor Mentorship program to see how the Core team can help graduates continue in an effective way.

There was a strong sentiment that this is a good opportunity to spot areas that lack appropriate documentation, need process adjustments, or need clarity, and a great chance to make contributor workflows more sustainable long term.

#core-committer-meetings, #core-committers

WCUS 2024 Core Committers Meeting Notes

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US last week, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) 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.

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

A group photo taken the day after the meeting. A few committers are missing that were present at the actual meeting. – Photo credit: @rzen with alternate angles form @afragen.

What is the right way to commit?

A newer committercommitter 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. mentioned that established committers have been very supportive and helpful getting them set up and comfortable. However, they often question whether they are doing things right. There is baseline documentation in the handbook around committing and some extensive documentation around commit messages, but every committer seems to have a different setup with a different tool set.

Some takeaways

  • There’s no wrong way to set up your environment or make commits.
  • To increase the amount of documentation around committing, every committer should blogblog (versus network, site) about their set up (and more about committing in general)! A new page has been created in the Core Handbook to serve as a blogroll for these posts and will be updated as new ones are published. Everyone is welcome to publish, including emeritus and committers who were not in attendance at WCUS.
  • Using the #core-committers channel for questions around committing process is always appropriate.

Clarity around requesting feedback

The next discussion was around how to properly seek feedback from other contributors and committers. The Make Core Blog has recently felt a bit too “official” for these more casual posts. But in the past, these types of posts were perfect for the Make Core blog. Is this no longer the place for these types of discussions?

The ideal purpose of Make Blogs was discussed a bit, and it was mentioned that there was a 2 part discussion at the 2023 Community Summit focused on this. It was suggested to read through the session notes to see if there were any mentions of this.

Some takeaways:

  • There’s value in posting on your own blog to validate your own ideas and understandings vs. speaking on behalf of WP to the community.
  • It’s OK to share posts on your blog seeking feedback as long as findings are summarized in the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker..
  • As long as it’s accompanied by a problem statement/theory/points needing validation, posting on the Make blog seeking feedback about that problem seems reasonable.
  • It’s always preferred to have a Trac ticket outlining the problem, even if it’s unclear whether it’s something that will actually be fixed (there’s always wontfix and maybelater).
  • Moving more “official” communication to the relatively new Developer blog makes sense. This would include the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page., developer notes, etc.
  • No matter where these discussion points are shared, make sure to be clear about what type of feedback you are seeking.
    • Is this idea unrealistic?
    • Are there blockers that are not apparent?
    • Is there history behind why something is a certain way that is not immediately obvious?
    • etc.

Props @jorbin for pre-publish review.

#core-committer-meetings, #core-committers

Aligning Committer-Level Access Across the Code Base

At WCEU 2024 Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/., several CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers and project leaders had an impromptu discussion about how to unify the permissions and capabilitiescapability capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). for the project’s committercommitter 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.-level contributors between the two code bases (GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ on GitHubGitHub 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 ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ and Core in SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.).

Present for the discussion: @desrosj, @jorbin, @youknowriad, @ellatrix, @bernhard-reiter, @chanthaboune, @matveb, @priethor, @gziolo.

Gutenberg is Core, and Core is Gutenberg. Ultimately, everyone works on the same software to achieve the project’s goals. Where that work occurs is not important. Suppose you are a contributor entrusted with privileged access to one part of the code base. In that case, there’s no reason why you should not have equivalent access in another location just because the tooling is different. Committers are trusted to make decisions, including the decision that they are not the best person to make specific decisions. Disparity in access leads to unnecessary bottlenecks and confusion around who can tackle specific tasks in specific areas.

As a first step to address this, the WordPress Core team on GitHub (consisting of all contributors with SVN commit access) has been given write access and the ability to merge pull requests to the Gutenberg repo. All Core Committers previously had this access, but this changed at some point, seemingly due to changes on GitHub.

Here are the rest of the proposed changes:

  • The Gutenberg Core Team on GitHub becomes a subset of the Core Committer list in SVN. To be on the Gutenberg Core Team, you must be a committer.
  • Going forward, the committer nomination process is required for any contributors to be added to the Gutenberg Core Team. To reiterate the current approval process: a public nomination in the #core-committers channel to field feedback from the community and a review/approval by @matt are required to grant anyone commit access (they would now receive commit access to SVN at the same time).
  • Bug GardenersBug Gardener A contributor who has been given advanced privileges in Trac. in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and the Gutenberg Team in GitHub become synonymous. Members of each group can request access to the other if it helps them contribute more effectively. Though members of the Gutenberg Team have write access on GitHub, no equivalent write access is given in SVN. This will be considered something similar to what was previously known as “guest commit.”

To truly align these two groups, everyone present at this discussion collectively nominated all Gutenberg Core Team members without SVN commit access: @0mirka00, @aaronrobertshaw, @andraganescu, @andrewserong, @aristath, @cbravobernal, @czapla, @get_dave, @glendaviesnz, @jameskoster, @joen, @kevin940726, @luisherranz, @mciampini, @mikachan, @nerrad, @ntsekouras, @ramonopoly, @richtabor, @scruffian, @talldanwp, @tyxla, @wildworks.

@matt approved these nominations after allowing 3 weeks for any feedback. Please join us in congratulating these contributors!

Over the next few weeks, these new committers will be on boarded and paired up with a current committer willing to be their buddy for their first few commits. Any of these nominees are also free to receive this access and not use it, or to decline the additional access should they feel it’s something they don’t want or won’t use.

If you’re one of the nominees, here are some required reading materials from the Core Handbook:

The process of adding these new committers will be tracked in Meta Trac in ticket 7722.

Props @jorbin, @cbringmann, @chanthaboune, @ellatrix, and @youknowriad for prepublish review.

#core-committers

New Committers: 2021

2021 has sped by with two major releases and a final one underway. These releases are made possible by many coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers who actively review and merge contributions (on top of other things). This year six new people were added to that list of committers, so please join me in welcoming and thanking them for their contributions.

First up is David Baumwald (@davidbaumwald). David served as Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Release LeadRelease Lead The community member ultimately responsible for the Release. for releases 5.3, 5.4, and 5.5 and has acted as a mentor throughout the 5.6 and 5.7 releases.  David has also served as a Component Maintainer for Comments.

Our next new committercommitter 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. is William Patton (@williampatton). William, a self-proclaimed lover of all things sandwich, has been a diligent contributor since 2010 and brought his expertise to the Theme Team and MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, and Plugins.

Jonny Harris (@spacedmonkey) has been an active member of the WordPress project since 2009! While Jonny is a professional WordPress developer, he gives back to the project by working in CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. and Core and working as one of our new committers.

Next up is Jeff Ong (@jffng)! Jeff’s introduction to WordPress began in 2013 when he made a blogblog (versus network, site) to document his media art. Fast forward to today, Jeff contributes 40 hours a week to the Themes team. In addition to seeing him in his committer role, you’ll often see his name associated with default themes (looking at you, Twenty Twenty-Two).

If you have visited our SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. #core channel, you will have seen our next committer, Jb Audras (@audrasjb). Jb is a current WordPress Core team representative, is one of the French General Translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. Editors since 2017, has acted as a Widgets and Menus components maintainer, and was an AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team representative. He has also been a focus lead on WordPress releases 5.3 (accessibility), 5.4 (documentation coordinator), 5.5 (accessibility lead), 5.6 (Core auto-updates wrangler), and 5.7 (documentation lead).

Marius Jensen (@clorith) began his WordPress journey in 2010, and since, his contributions span from bbPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org. to Core to translations. Marius is a warm presence in the support forums and has made a positive impact on the Project with his work on the Site Health feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., the jQuery upgrade, and is now a Core committer.

Last but certainly not least is the inimitable Tonya Mork (@hellofromtonya). Tonya has been part of WordPress since 2015 and has since been triage lead for WordPress releases 5.6 and 5.7, a team representative for Test, and is now a Core committer!

Please join me in congratulating this excellent cohort of committers! 🎉💫

#committers

#commit, #core-committers