The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
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 SourceOpen 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.
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 accessibilityAccessibilityAccessibility (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.
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/CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. posts, issue and PR threads on GithubGitHubGitHub 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 LeadThe 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 noteEach 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, P2P2A 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 bugbugA 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.
Run various release processes in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (betaBetaA 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 candidateOne 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)
Keep an eye on the deadlines in the handbook and contact the different teams involved (pingPingThe 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.”pluginPluginA 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
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 triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. core tickets(in tracTracAn 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
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 candidateOne 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.
This role is split into two main areas – Product, and release.
The “product” area comprises the work going into the actual UIUIUser interface/UXUXUser experience of WordPress.
The “release” area includes coordinating release-specific materials (like the About page).
Provide guidance and decision-making on core and blockBlockBlock 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 releaseA 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:
Keep track of changes within the release that require dev notes. This includes GutenbergGutenbergThe 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 committercommitterA 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 ticketticketCreated 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 GuideField guideThe 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)
Proofread and review dev notes before publication.
If a ticket participant is not available to write a dev notedev noteEach 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)
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.
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 example)
Help with Gutenberg ⇔ Core sync/updates through Trac tickets (More details here)
Make sure the Gutenberg props get collected properly
Communication with the rest of the release squad about:
Documenting the updates from Gutenberg included in the release and on each Core beta/RC
Highlighting 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.
Communication with all contributors to get features and enhancements ready in time, help them out if needed.
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.
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/severityseverityThe 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
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
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 APIAPIAn 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 enhancementenhancementEnhancements 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)
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.
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.orgThe 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
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 puntpuntContributors 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
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.
Coordinating and leading efforts to increase testing of beta releases, release candidate releases, final release, and where feasible everyday trunktrunkA 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.
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.