Summary, Dev Chat, March 13, 2024

Start of the meeting 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/., facilitated by @joemcgill.

Announcements

WordPress 6.5 RC 2 was released yesterday, March 12, 2024 and Gutenberg 17.9 was released earlier today. Please continue to help test and provide feedback.

Forthcoming Releases

Next 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.: 6.5

We are in the final weeks before WordPress 6.5 is scheduled to be released, with our final scheduled 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). (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). 3) scheduled for next week.

There are several important changes to our normal development process during the RC stage. For more, see this post: WordPress 6.5 Release Candidate Phase.

Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 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. 3.

@marybaum confirmed the release team for RC3 on Tuesday, March 19, 2024. @audrasjb as 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., with @hellofromtonya on backup and @davidbaumwald as mcpilot; @akshaya will host with @priethor as backup.

@swissspidy also shared that RC3 is the last scheduled RC before the stable release. The topmost priority should be solving the Font Library uploads location as per Josepha’s recent blog post. If you would like to help, there is an open architecture discussion where you can get involved, and a couple of remaining related PRs:

• Add a database persisted fallback for the default font folder path
• Add fallback for the default font folder path
• Fix naive filtering of uploads directory

Primarily, we need to find a robust way to ensure that, when deleting a font, the font files are deleted from the right folder. If we don’t have a solution for the above by RC3 we could consider an additional fourth RC.

There are also some open Interactivity API bugs and editor bugs, but nothing severe. It would be helpful if these issues had owners. @joemcgill suggested scheduling another 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. scrub this week to review these issues and assign owners.

Next 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/ release: 18.0

Gutenberg 18.0 is scheduled for release on March 27 and will include these issues.

Discussion

The discussion today started with organizing release squads for 6.5.x and 6.6 releases.

@jorbin confirmed that we’re still looking for folks to be involved in the 6.5.x maintenance releases. Please reach out if you’re available to help with these releases – particularly if you were already involved in the 6.5 releases (but that’s not a requirement).

@priethor has a draft for a post that identifies people who have raised their hands for 6.6.

A related discussion topic is whether we should reevaluate the size of release squads prior to 6.6. This came out of the discussion following the 6.5 release squad announcement (context). There was a discussion around the pros and cons of having larger release squads, including:

• Larger squads spread the responsibility that used to be focused on just one person to a bigger team. However;
• It doesn’t feel like there is much need for others to help or be involved when there are so many people responsible for a release.
• The more individuals, the greater number of relationships and opportunities for both cliques and interpersonal conflictconflict A 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..
• It sometimes leaves the team not knowing who should be making key decisions about features.

There were also suggestions for better documenting the responsibilities both within the release squad and within a lead group. Also, having feature leads would be helpful, i.e. folks spearheading and owning a specific big feature in a release.

@joemcgill suggested that we could review the release squad size as part of a debrief post for 6.5, and @priethor is working on a proposal for a reduced release squad that will be published in the upcoming days.

Props to @joemcgill for reviewing.

#6-5, #dev-chat, #summary