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.
WordPress 6.6 Planning Proposal & Call for Volunteers
Please leave your feedback about the schedule and release squad size in the comments by April 7th.
If you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the role and the type of involvement (lead/cohort).
With WordPress 6.5 almost ready, it’s time to start planning WordPress 6.6 so that the release leads can participate from the start of the release cycle.
The timeline for the second release of 2024 takes into consideration WordCampWordCampWordCamps 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 in June, WordCamp US in mid-September, and the observed lower number of contributors available during the northern hemisphere summer. To avoid having major milestones (Beta1, RC1) conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with flagship events, this proposal suggests having WordPress 6.6 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. 1 before WCEU 2024, as the opposite would result in an even shorter release cycle for WordPress 6.7.
According to the schedule proposed below and the 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/ release cadence, WordPress 6.6 would include up to Gutenberg 18.5 for a total of 8 Gutenberg releases.
Proposed WordPress 6.6 Schedule
Milestone
Date
Alpha (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. open for 6.6 release)
March 5, 2024
Beta 1
June 4, 2024
Beta 2
June 11, 2024
Beta 3
June 18, 2024
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). 1
June 25, 2024
Release Candidate 2
July 2, 2024
Release Candidate 3
July 9, 2024
Dry Run
July 15, 2024
WordPress 6.6 General Release
July 16, 2024
Please leave your feedback about the schedule in the comments by April 7th.
Release Leads call for volunteers
Having more than one lead per role has proven helpful in sharing responsibilities, especially in the case of unexpected events, and fostering leadership by pairing experienced leads with first-timers. However, recent feedback has also pointed in the opposite direction, with the squad having too many voices when combining role duplicity with the increased number of different roles. These larger squads have also fostered a bystander effect, creating the sometimes false feeling that somebody else must be working on things, resulting in unclear direction.
Since this release cycle is shorter than the last ones, I propose scaling back the release squad size again, trying to find a middle ground. Reducing role duplicity is less risky at this point as, in the event of unexpected release leadRelease LeadThe community member ultimately responsible for the Release. availability, plenty of now-experienced contributors are ready to step up and lend a hand in case of necessity.
This squad reduction also includes experimenting with unifying the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and Editor TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. roles so that the Triage Leads have a wider picture of issues across the technical side and can act as a nexus between Core and Editor Tech Leads.
With this smaller release squad, release leads should have proven experience and good availability during the release cycle. Less experienced folks and newcomers are still welcome to join as a cohort.
Some folks have already volunteered in the previous call for volunteers; some roles are already filled, whereas availability has changed for some people and there are still open spots. The TBDs found in the list below indicate the number of desired vacancies to fill.
* Both Triage Leads had volunteered for either Core or Editor Triage roles.
All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.
As a reminder, if you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the desired role and level of involvement (lead/cohort).
