WordPress Release Team and Focus Leads

Each new WordPress software release is a substantial undertaking that can only succeed through the dedication and support of hundreds of contributors. 

The work can span many months and involves all areas of the global project. Each release is managed by a changing group of active contributors who take ownership of its various aspects. This group is known as the ‘Release Team’ for the particular software version. It coordinates across all the teams to connect ideas and solutions and make the release as effective as possible.

Members of each Release Team come from a variety of backgrounds and skillsets. They should have a thorough understanding of the WordPress software and the community, but also of 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. web development. In addition, they have good communication and project management skills.

This page explains the various roles involved with a given release and the type of tasks involved. 

Release Team

The main focus of the release team is to lead the release from its beginning through to launch. This requires members to act as connectors and facilitators, resolving bottlenecks and issues. 

A new release affects all the moving parts of the software. Any newly introduced, or amended feature could potentially:

  • affect existing plugins
  • have an impact on the 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) of both front-end and back-end of the platform
  • and so much more.

It is therefore vital to have representatives from all fields of expertise in the Release Team. Each will take responsibility for a particular aspect and act as an advocate during the process. 

In addition, it is crucial that all changes are thoroughly documented. This also helps all stakeholders to be involved.

During the course of a development cycle, the Release Team is joined by hundreds of contributors. These contributors collectively work on a range of tasks, guided and mentored by both Release Team members, and other experienced contributors. 

Historically, not all releases have included representatives from every area of the platform. Minor releases may not need the involvement of all teams. Some of the most commonly seen release team roles are listed below.

Top ↑

Release team roles

To cover all situations, ideally each lead role in a release should have at least two people.

Top ↑

Shared Responsibilities

These are tasks and responsibilities that may be documented for specific roles below but can be taken on by anyone throughout the release cycle.

  • Communicating publicly as much as possible (on tickets, in component chats, Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. posts, issue and PR threads 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/, etc.).
  • Identifying blockers to progress and asking for help from buddies, team leads, and/or the Release LeadRelease Lead The community member ultimately responsible for the Release..
  • Being mindful of deadlines.
  • Identifying changes that require documentation, HelpHub articles, or communication to the community at large (through dev notesdev 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., marketing, P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. posts, etc.), and communicating with the documentation team about such changes.
  • Leading 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. scrubs focused on your team’s tickets and tasks.
  • Facilitating and participating in inter-team discussions.
  • Always be testing!

Top ↑

Release lead

Responsibilities

  • Set the overall goals and main focus for the release
  • Make final decisions on merging feature plugins
  • Give final review to and publish news blogblog (versus network, site) post announcing the release. Older ones can be found on this page
  • Coordinate with Matt to select release jazz musician. This is only done for major releases, and are documented on the WordPress versions page.

Top ↑

Release Coordinator

Responsibilities

  • Run various release processes 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/. (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., release candidaterelease 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)., release)
  • Write blog posts for various milestones
  • Keep an eye on the deadlines in the handbook and contact the different teams involved (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.” 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, theme, ping polyglots, etc.). Remind people of said deadlines when needed.
  • Take notes on the procedures outlined in the handbook to propose changes if needed
  • Facilitate inter-team discussions if needed
  • Maintain a birds-eye view of the moving parts for any red flags, blockers, or additional help needed for teams

Top ↑

Core Triage Lead

Responsibilities

  • Run Bug Scrubs
  • Run various release processes in Slack with the Release Coordinator (beta, release candidate, release). These are detailed in the process detailed in this document.
  • Attempt to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. core tickets(in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.) in the release’s milestone
  • Prioritize tickets to ensure that the most time-sensitive and urgent issues are given the necessary exposure within the group to garner a fast resolution
  • Communicate with component maintainers to gauge where more resources/attention is needed

Top ↑

Core Tech Lead

Responsibilities

  • Review core patches and changesets for feasibility, code quality, technical design, and coding standards compliance. Ensure they follow the overall software architecture.
  • Provide a “second opinion” and technical guidance where requested or needed.
  • Ensure the release cycle stages are followed by all contributors. For example — no enhancements during the beta, unless an exception was proposed and approved by project leadership
  • Ensure the beta, 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). and final release processes run as smoothly as possible on the technical side, and all release steps are completed
  • This role is also responsible for escalating cases and helping to make decisions when new features, enhancements, and (large) bug-fixes are not ready in time. For example — if a new feature is not 100% complete before beta, and/or the code is still “alpha” quality and needs more work. In such cases, the core tech lead would facilitate reviews and gather more information to decide whether to proceed with the feature or add it in the next release. These cases are usually escalated to project leadership.

Top ↑

Design Lead

Responsibilities

  • This role is split into two main areas – Product, and release.
    • The “product” area comprises the work going into the actual UIUI User interface/UXUX User experience of WordPress.
    • The “release” area includes coordinating release-specific materials (like the About page).
  • Provide guidance and decision-making on core and 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. editor tickets that need any design input.
  • Coordinate design and copy for various release assets.
    • Guiding the creation of the highlight grid and microsite for each WordPress release. This includes the unique about page that ships with each 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., and shows up in wp-adminadmin (and super admin). Examples of previous highlight grids for reference:
    • Work on, and provide design support for creating social media assets for each release.
    • Decide and design the artwork for the jazz musician associated with each major release

Top ↑

Documentation Wrangling

Responsibilities

  • Publish 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. on RC1 release date (Example from the WP 6.6 release
  • Manage writing and publishing of dev notes
    • Keep track of changes within the release that require dev notes. This includes 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/ PRs for all releases of the plugin between two core releases
    • Coordinate with the participants of those tickets/PRs with the best understanding of the changes (the 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., component maintainers, contributors who own a ticketticket Created for both bug reports and feature development on the bug tracker./PR) to draft dev notes
    • Ensure all dev notes are written with enough time to proofread, reviewed, and published before the field guide (which publishes at the same time as release candidate 1)
    • If a ticket participant is not available to write a 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., finding someone to write one, or writing one yourself
  • Ensure any documentation pages required for new features are created before the release
  • Write and publish the release changelog on HelpHub (Example for 6.5)
  • Update version-specific developer reference (Example for 6.5)
  • Update the WordPress versions page

Top ↑

MarComms (Marketing and Communications) Lead

Responsibilities

  • Collaborate with release leads and contributors to draft Marketing and Communications (MarComms) deliverables, including:
    • Beta & Release Candidate announcement posts
    • General release announcement post
    • About page and microsite content
  • Ensure the content for these deliverables is written and ready for proofreading and review with enough time, follows the WordPress.org Brand Writing Style Guide, and accurately reflects the release features and benefits.
  • Collaborate with release design contributors on creative and visual assets such as the highlight grid, featurettes, and/or other social media visuals for release marketing and communication purposes.
  • Help develop or collaborate with marketing contributors on a social media posting plan to promote the release milestones and key features.
  • For a comprehensive guide to this role’s tasks, visit the Marketing Communications Release Cycle Guide.

Top ↑

Editor Tech Lead 

Responsibilities

  • Loosely help define what Gutenberg features can/should get included in the release
  • Triage and review patches and PRs, test RCs, and coordinates meetings for the block editor
  • Ensure all Gutenberg features and bug fixes land on time before each Core beta/RC
  • Gather a list of important Gutenberg bugs and regressions that need to be fixed on each release. Ensure the contributors know about these and their importance (Project board)
  • Help with Gutenberg ⇔ Core sync/updates through Trac tickets
  • Make sure the Gutenberg props get collected properly
  • Make sure the Gutenberg release notes get published on time
  • Communication with the rest of the release squad about:
    • document the updates from Gutenberg included in the release and on each Core beta/RC
    • highlight the important features and updates for the marketing team and for the About page.
    • co-ordination with other leads
  • Make sure Gutenberg updates get shipped in Core releases on time, with as few bugs as possible, and get communicated properly

Top ↑

Editor Triage Lead

Responsibilities

  • This role is similar to the Core triage lead role, but focuses mainly on the development of the block editor, and integrating it in core releases.
  • Run Bug Scrubs focused on Editor items. This is done in the #core-editor channel on Slack.
  • Review incoming tickets to the Gutenberg GitHub repo to ensure items are labeled appropriately for further review, including adding anything necessary to the appropriate release specific project board.
  • Communicate with the Core Editor Tech leads to help gauge where more resources/attention is needed.
  • Help prioritize any key issues throughout the release cycle to ensure time sensitive and urgent problems are resolved promptly.

This work is done in collaboration and coordination with the Core Tech leads so please refer to Block Editor Release Process for Major Releases for a more detailed and practical look.

Top ↑

Accessibility Lead

Responsibilities

  • Set up priorities for the release and define a general scope for the accessibility focus
  • Triage all other tickets that are not in the main priority for the release and make choices based on priority/severityseverity The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs.
  • Organize/run accessibility bug scrubs (1 accessibility focused scrub per week)
  • Contribute to tickets from various components to give accessibility feedback on both Trac and Gutenberg GitHub repository
  • Write accessibility-related documentation and publish it on Make/Core (dev notes) or HelpHub as necessary
  • Coordinate with the design and media teams to keep the release scope on its way.
  • Open tickets/issues on Trac/GitHub to handle potential accessibility regressions on all the components during the entirety of the release process
  • Communicate about the release scope and progress updates on Make/Accessibility and during core dev chats
  • Ensure patches are solid, reviewed, and committed in time
  • Contribute to ticket patches with code, tests, screenshots, code, and design reviews, etc
  • Provide accessibility-related reviews and contributions to ensure accessibility standards are met

Top ↑

Performance Lead

Responsibilities

  • Set up priorities for the release and define a general scope for the performance focus by estimating both horizontal impact (“how many sites does this apply to?”) and vertical impact (“how much does this improve performance for sites where it applies?”)
  • Regularly triage tickets in the milestone that fall outside of the main priorities, following up with the reporter and other contributors involved
  • Assess feasibility of committing a fix for specific tickets in the current release cycle, based on priority, severity, effort and time needed, contributor availability, time left in the cycle
  • Join or lead regular performance bug scrubs and other performance related meetings
  • Benchmark performance of relevant pull requests / patches from various components (in both Trac and Gutenberg), both proactively and on demand, focusing primarily on tickets that are one of the following:
    • A new feature or 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. planned for the release
    • A performance enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. or fix that is intended to improve performance
    • Another change that suggests to have a measurable performance impact (whether positive or negative)
  • Work with team members to ensure performance measurement best practices are followed and clearly communicated
  • Monitor the WordPress core performance dashboard regularly to identify potential performance regressions and report them back to the relevant ticket for which the underlying change was committed
  • Coordinate with other release leads, primarily the Core Tech and Editor Tech Leads to support their priorities with performance guidance
  • Communicate about the release scope and progress updates in the release leads Slack channel and during core dev chats
  • Work with the Documentation Lead to ensure timely publishing of performance related dev note posts prior to or early in the beta phase
  • Support team members contributing to tickets in the performance focus, e.g. through triaging, coordinating team members to help with feedback, code review, and benchmarking, as well as guidance on communication and documentation related tasks such as enhancing WordPress core documentation or writing dev notes
  • Coordinate the contributions to tickets, pull requests/patches, tests, performance benchmarks, code reviews, etc.

Top ↑

Default Theme

A new default theme will be bundled together with the last release of the year. This task needs a number of roles. 

Top ↑

Default Theme Design

Responsibilities

  • Create drafts for the default theme design, iterate on those drafts, and polish the design selected as the final candidate
  • Introduce the design on the Make Core/Make Themes blogs
  • Update the design as needed throughout the process
  • Participate in meetings (and occasionally lead them) in #core-themes
  • Contribute code to the theme, mostly front-end heavy stuff
  • Document the theme features and behavior, both to guide development (in issues and PRs) and for the support pages on 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/
  • Review issues and PRs, primarily design-related ones

Top ↑

Default Theme Development

Responsibilities

  • Leading implementation for major designs crafted by Default Theme Design Lead
  • Providing technical guidance and review for others assisting with implementing designs from Default Theme Design Lead
  • Create issues and PR’s as I found bugs within the theme
  • Organize issues and PR’s with labels
  • Run the weekly new default theme meeting in #core-themes
  • Close duplicate issues and issues which were not within the scope of our timeline or were decided against by the #core-themes team
  • Review issues and PRs, marking them for `commit` them as needed
  • Approve and review default theme tickets (other than a new default theme being built for the same release) in the milestone and puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) tickets when necessary
  • Manage the development of the new default theme and help everyone involved stay focused on tasks and the short timeline
  • Package the theme for upload to the theme directory for each phase of the release

Top ↑

Default Theme Wrangler

Responsibilities

  • Guarantee that all default themes fully support any new features added in the current release (as deemed appropriate).
  • Triage tickets in the Bundled Theme component in Trac
  • Manage tickets and decide what is ready, what is not, and what should not be included
  • Mark tickets for `commit` when they are tested and confirmed to be ready
  • Communicate with the new default theme designers and developers to use a common approach when adding support for new features

Top ↑

Support

Responsibilities

  • Have a presence in the WordPress.org support forums during phases 2-4 of the release cycle keeping an eye on the Alpha/Beta/RC forum
  • Bring any potential problems reported there to the attention of the appropriate release team member
  • Help respond to posts with no replies
  • If you speak a language other than English, check out the list of non-English support forums and provide support
  • If there are common questions appearing in the forums, bring it to the attention of the release team so that new user documentation pages can be created.

Top ↑

Test

Responsibilities

  • Coordinating and leading efforts to increase testing of beta releases, release candidate releases, final release, and where feasible everyday 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./nightly builds in an effort to provide real-world testing feedback to the rest of the release team.
  • Amplify testing efforts and opportunities, including helping onboard folks who are interested in helping or doing round up posts for feature specific testing
  • Attend test meetings as much as possible to communicate priorities for testing to the community.
  • Work with teams to ensure any necessary testing for new features or big changes (example: Gallery Block refactor).
  • As possible, improve documentation for testing related items to help more folks get involved.

The section above outlines the roles for the Release Team rather than the work of the individual core teams and their work towards a release launch. To learn more about how the Make Teams contribute to the current release cycle, visit the development blog.

Top ↑

Further resources

Last updated: