Héctor Prieto 4:52 pm on January 18, 2024
Tags: 6-5 ( 76 )

WordPress 6.5 release squad formation

Following up on the last call for volunteers, I’m pleased to announce the release squad for the upcoming WordPress 6.5 has been put together in collaboration with project leadership.

The release squad formation is as follows:

Release LeadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg
Release Coordinators: Akshaya Rane, Héctor Prieto, Mary Baum
CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Leads: David Baumwald, Pascal Birchler
Editor Tech Leads: David Smith, Riad Benguella
Core Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: Ahmed Kabir Chaion, Jb Audras, Rajin Sharwar
Editor Triage Leads: Anne McCarthy, Fabian Kägy
Design Leads: Benjamin Zekavica, Rich Tabor
Marketing and Communication Leads: Dan Soschin, Lauren Stein
Documentation Leads: Estela Rueda, Leonardus Nugraha
Performance Leads: Joe McGill, Mukesh Panchal
Test Leads: Olga Gleckler, Patrick Lumumba, Vipul Ghori
Default Themes Leads: Carolina Nymark

This release squad introduces an experimental Default Themes Lead role based on the need to update past default themes due to changes introduced in releases.

As a reminder, the next milestone is WordPress 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. 1, scheduled for February 13th. You can check the WordPress 6.5 Development Cycle page for a more comprehensive schedule.

Thanks, everybody, for volunteering for this and upcoming release squads! There are already a handful of volunteers for 6.6 and 6.7; this will help set up the 6.6 release squad as soon as 6.5 is launched. Those who volunteered as cohorts, would like to learn the ropes for future releases, or follow the process in general, are welcome to join us in the #6-5-release-leads Slack channel.

Let’s work together on yet another successful WordPress release!

Thanks to @chanthaboune and @cbringmann for collaborating in the squad formation and reviewing the post.

#6-5

Aaron Jorbin 5:03 pm on January 18, 2024

> this will help set up the 6.6 release squad as soon as 6.5 is launched

This is waiting too long and will essentially mean that the 6.6 squad is in place just as late in the release cycle as this one. What would you think of a target for the 6.6. squad to be named before RC1 of 6.5?
- Héctor Prieto 5:17 pm on January 18, 2024
  
  We don’t have enough volunteers for all the 6.6 roles yet, but I agree the goal should be to have the next release squad in place by the time of the stable release, if not earlier.
  
  With this in mind, I think having a second 6.6 call for volunteers around RC1 to announce the 6.6 squad by the 6.5 stable release is a good step forward; what do you think?
  - grafruessel 6:53 pm on January 18, 2024
    
    Is there a list somewhere about the missing 6.6 roles?
  - Jeffrey Paul 7:06 pm on January 18, 2024
    
    If we had a call for 6.6 leads after 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. 1 so that we could announce the 6.6 team after rc 1, then that would give that new team some time to start forming and seeing what items fell out of 6.5 to start tracking for 6.6?
    - Aaron Jorbin 7:13 pm on January 18, 2024
      
      This along with moving back to smaller squads as @jeffpaul mentions below seems like a great way to move to getting release squads running from day 1.
Jeffrey Paul 7:11 pm on January 18, 2024

On top of trying to improve the timing on when we’re able to confirm a release square (as @jorbin‘s comment starts the conversation on), I’d also like to question the size of the release squads. Without having thought things through too significantly, what if the formal squad was reduced to a Release LeadRelease Lead The community member ultimately responsible for the Release., 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)., CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Lead, and Editor Lead? The various Make Team Reps from associated teams could identify who from their team would lead their efforts, possibly with those specific tasks and comms happening within that team’s 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./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/./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//whatever tooling, and could chime in the release lead channel as necessary but otherwise limit the number of actually leading a release? The leads from the various Make Teams could still result in Noteworthy Contributors in the release credits, but in having a smaller named leads for the squad should also reduce the time it takes to confirm that squad?
- Héctor Prieto 7:29 pm on January 18, 2024
  
  If there is an expectation for Team Reps to coordinate the support in their area of expertise, I don’t see any reason not to reevaluate the release squad size and try to reduce it.
  
  On the other hand, since I joined the project, the feedback I’ve seen goes in the opposite direction: adding more roles to the squad, the latest two being the Performance and Default Themes leads, whose tasks could also be done by the respective team members. It seems this is worth discussing with leadership (cc @chanthaboune).
  
  My humble opinion is that the project’s scope is growing, and I would be very wary of oversimplifying the squad (similarly to how careful we need to be not to overcomplicate it!). For example, the Editor scope is so massive nowadays that I don’t see how just a combination of a couple of Editor Tech Leads with the help of Release Coordinator(s) can handle the whole Editor scope. 😅
  - Jeffrey Paul 7:53 pm on January 18, 2024
    
    I would recommend separating the Editor lead role and its accountability from the various people responsible for various editor-related features targeted for a specific release. The Editor lead can coordinate with those across the editor team and frankly should themselves probably not be responsible for more than one feature so that they’re able to coordinate across all the folks responsible editor features within a 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..
- Andrew Ozz 8:44 pm on January 18, 2024
  
  I’d also like to question the size of the release squads.
  
  Historically there were only release leads (one person) for quite a few years. That person was supposed to do everything: review patches and new features, commit, test, coordinate commits and testing, make the hard decisions whether something should be punted if not ready in time or not “ready enough”, etc. However the tasks associated with leading a release are a lot, and getting more and more complex all the time. Eventually “release sub-leads” were added to help the leads, but the amount of work and pressure were still very high.
  
  Fast forward to today, I think it is much better that there are many people that are looking after more specific tasks for a release, and that more than one person looks after each task. This lightens the load and takes away the pressure especially around 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.-1 and 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)..
  
  Going back to having only 2-3 dedicated release leads doesn’t sound very appealing imho.
Andrew Ozz 8:24 pm on January 18, 2024

The squad looks great imho! As always, happy to help or answer any (not-so-standard) questions that may arise 🙂
Jonathan Desrosiers 7:16 pm on January 19, 2024

This looks like a great squad! Looking forward to the release.

I did want to chime in and say that I agree with the sentiment above that our release squads are becoming a bit too large for my own liking. It feels like we’re getting into the “too many cooks spoil the broth” territory.

While I recognize that the project is grown substantially since the days of having only a Release LeadRelease Lead The community member ultimately responsible for the Release. and Release Deputy, I think that 26 people is probably too far to the other extreme.

One thing I think that’s important to underscore is that a release does not begin when a release squad is finally assembled. Work by teams and contributors should be happening continuously as they’re able to give their time, effort, and attention to items

The squad should not be responsible for setting direction or deciding what contributors work on. That’s what our project goals and priorities do. The continuous contributor efforts should naturally fall into the paths that progress us towards those, and what ends up in each release should happen somewhat organically.

I’d like to explore ways we can better empower teams to continue this work in the absence of a specifically appointed squad. Then release squad members (when announced) can observe what work is ongoing under their specific purview with the contributors leading these features/initiatives/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. fixes reporting up to them. They can then report status updates to the rest of the squad, community, and leadership while mentoring those contributors, providing guidance to stay on track, making any needed final decisions with all available information, and ensuring the work results in a quality release that we can all be proud of.

Comments are closed.

Welcome!

Communication

Share this: