Tag Archives: core-committer-meetings

Jonathan Desrosiers 7:43 pm on November 26, 2025
Tags: committers, core-committer-meetings   

Core Committers Check-in – November 2025

This post summarizes key discussions from the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 held on November 25, 2025 with project leadership. As with previous check-ins, the goal is to align on key initiatives, gather feedback, and clarify next steps for the WordPress project.

Note: This meeting followed the Chatham House Rule.

Purpose of these meetings

The group briefly discussed what the goals of these meetings are and which groups are ideal to include. Contributors have asked if only committers are invited, or if broader groups are allowed to join as well (component maintainers, team reps, etc.).

After discussing, the following was agreed upon:

  • These meetings are most valuable when committers only attend plus a small group of invited contributors who support that group in establishing and accomplishing project-level goals.
  • This creates a safe space for free, honest, and frank conversations, which is the most prominent reason why these meetings are valuable. 
  • There is certainly value in having more frequent open forums for wider audiences. These should have narrower focuses, and could have guest speakers, and field some questions ahead of time.

Looking ahead: 2026

The next topic of conversation was forward facing around the planning for 2026 and beyond.

Release Planning Post-6.9

The first item related to 2026 planning discussed was to seek clarification on the rough plan for releases going forward.

The main point to underscore out of this discussion is that the intention in 2026 is to return to a cadence of 3 major releases per year. A release in February was proposed, but most felt that was too short.

  • December is really quiet as many people take time off to end the year.
  • February release would mean 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. 1 very early in January, leaving just over a month for an alpha period.
  • The features that are being worked on would likely not be ready in time for a February release (more on these later).

March or April was suggested, and there was a higher level of confidence in that target.

Lining up the release day of 6.9 with 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/. is an experiment of a new way to celebrate a release. If it goes well, future major releases could be planned to coincide with flagship events. However, this could be complicated and may require additional planning from leadership and involvement with contributors that help plan release cycles.

  • Events are typically planned around budget, venue availability, and regional factors such as the predominant religious holidays or weather patterns.
  • It could limit options for release squad members due to availability issues because of time zone differences, or for people who are traveling to and from the events leading up to release day.

Targeted release dates are also influenced by the features being targeted for each release. So which features are targeted for 7.0?

Possible Features for 7.0

To start this conversation, features that were removed from or were not ready in time for 6.9 were mentioned. These included:

  • Template activation
  • The tabs 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.
  • Client side abilities for the Abilities 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.

This rough draft document was shared. Someone in attendance uses this as a way to track any ongoing UXUX User experience/UIUI User interface improvements, who is responsible, their high-level status, etc. and will be turned into a proper post in the near future.

Some other features explicitly discussed:

  • WP AI Client work
  • Client-side media editing

The status of the adminadmin (and super admin) redesign project was mentioned. The intention of this was clarified. It’s not about completely redesigning the admin area. It’s more about giving it a new coat of paint and refreshing what is already there. How can we revive WP Admin?

  • How can the settings screens be improved?
  • The view transitions 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 is quite nice and makes the admin feel more modern and refreshed.
  • Site Health and the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher upgrade warning in the dashboard have gotten really scary and overwhelming. How can these be more approachable, useful, and informative?
  • Can the dashboard be used more effectively?
    • The About page is seen by so few people today with many sites auto-updating major releases.
    • Are there new ways to inform the user about an update that happened? Or educate them on how to better take advantage of newly added features?
    • Previously, the welcome 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. was updated with each release, but that practice has stopped.
    • Are there new widgets that can be added, such as “on this day” or “new/unresolved notes” for sites making use of the Notes feature.

WordPress AI Client in Core

Work continues on the AI Client parallel to releases. Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

  • Core will always remain agnostic. Including a specific model or only integrating with some third-party services is not sustainable.
  • Features can be conditionally available based on the presence of an AI model.
  • Open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. models could be used. But oftentimes the experience is bad.
    • Models are quite large.
    • They must download on a per-site basis, which takes time and disk space (even the smallest models are approaching 1GB)
  • Machine-based models such as Apple Intelligence may be an option.

A few more promising initiatives/approaches were discussed.

  1. Browsers are working towards including models within the browser. This means they would already be installed on a user’s machine, and all data stays local.
  2. The W3C WebML working group is working to standardize these tools.

AI can be implemented in a way that browser-based models can be overridden but serve as the fallback/default when no other models or services are configured. In some recent experiments, browser-based models have shown to be very strong when put up against small, state of the art ones.

One exercise that could be helpful is to step back and consider what the use cases are in default WordPress before picking a model. A few possible use cases were mentioned:

  • Searching the media library for specific subject matter within images.
  • Creating a newsletter based on recent content.

An area of improvement for the group is the story being told. How do the tools being built improve WordPress? How do they benefit the user? How does work being done today open the door for empowering functionality later?

A few more ideas were thrown out as ways to improve how well LLMs work with and for WordPress:

  • Improving code base documentation helps LLMs understand the code base better.
  • Including “build for WordPress” as a benchmark within models.
  • Ensure site content and WordPress is accessible for models.
  • Tools like PHPStan and languages such as TypeScript with stricter typing help make the code base more consumable and easier to understand

Raising the minimum required PHP version to 7.4

This conversation focused on the compelling reasons for changing the project’s support policy.

  • Raising the minimum allows the project to move forward with new features.
  • It’s a balance between bringing users with us and not being held back.
  • Not about leaving people behind.
  • PHP 7.4 moves the needle in the direction of being more heavily-typed (see previous TypeScript point above), making it easier for AI models to ingest and understand.
  • There’s a good amount of bloat in the code base that only remains to support older versions of PHP.
  • AI-related SDKs from third-parties have varying minimum PHP requirements. Keeping the minimum required version of PHP too low prevents using some of these.

Understanding Responsible Parties

Throughout the 6.9 release, it was helpful to know who was responsible for or leading efforts for a given feature. It helps the community to better understand where there are gaps and where they can pitch in to help.

When looking at the potential 7.0 features (and beyond), efforts will be made to continue this practice.

Follow Up Action Items

  • Propose additional open/semi-open meeting formats for wider community groups and increased transparency (@4thhubbard & @desrosj).
  • Publish a release schedule for 2026.
  • Determine the targeted features for 7.0 (and possibly 7.1).
  • Consider what would be needed to regularly coordinate release days to coincide with in-person events.

The agenda and raw notes for this meeting are available in Google Docs.

Props @4thhubbard for review.

#committers, #core-committer-meetings

Aaron Jorbin 1:14 pm on September 18, 2025
Tags: , core-committer-meetings, ,   

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

Jonathan Desrosiers 12:18 am on June 13, 2025
Tags: core-committer-meetings,   

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

Mary Hubbard 4:43 pm on April 4, 2025
Tags: core-committer-meetings,   

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

Jonathan Desrosiers 5:22 am on February 22, 2025
Tags: core-committer-meetings,   

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

Jonathan Desrosiers 5:12 pm on September 27, 2024
Tags: core-committer-meetings,   

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