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, 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, etc.).
  • 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 for the release
  • Make final decisions on merging feature plugins
  • Give final review to and publishing News blogblog (versus network, site) post announcing the release
  • Coordinate with Matt to select release jazz musician

Top ↑

Release Coordinator

Responsibilities

  • Publish the weekly dev chat agendas
  • Run the weekly dev chat in #core
  • 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
  • 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 dev chats when Release Coordinator is unavailable
  • Run various release processes in Slack with the Release Coordinator (beta, release candidate, release)
  • Attempt to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. tickets 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 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, facilitate reviews and gather more information in order to make a decision whether to proceed with the feature or add it in the next release. These cases are usually escalated to project leadership

Top ↑

Core Design Lead

Responsibilities

  • Provide design input, guidance, and mockups for key TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

Top ↑

Documentation Wrangling

Responsibilities

  • Keep track of changes within the release that require dev notes
  • Coordinate with the participants of those tickets 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 owned a ticketticket Created for both bug reports and feature development on the bug tracker., and lead the charge) to draft dev notes
  • Ensure all dev notes are written with enough time to proofread, reviewed, and published prior to 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. (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
  • Update WordPress versions page on the Codex

Top ↑

Documentation Review

Responsibilities

  • Proofread and review dev notes as they are available from the Documentation Wrangling team
  • Verify code examples
  • Make suggestions for additional examples
  • Ensure the developer notes accurately and thoroughly describe the problem, solution, and identify proper usage of the changes

Top ↑

MarComms (Marketing and Communications) Lead

Responsibilities

  • Work with leads to draft the About page seen in the WordPress Adminadmin (and super admin) after upgrading
  • Work with leads to draft 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 blog announcement post
  • View a comprehensive guide for this role’s tasks here.

Top ↑

Editor Tech Lead 

Responsibilities

  • Loosely help define what 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/ features can/should get included in the release
  • Triage and review patches and PRs, test RCs, and coordinates meetings for the 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
  • 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

  • Run Bug Scrubs focused on Editor items.
  • 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 ↑

Editor Design Lead

Responsibilities

  • Provide design input, guidance, and mockups for key block editor tickets

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