This post summarizes the feedback received from the WordPress 6.4 retrospective. Thank you to those who contributed their feedback via the retrospective survey and comments on the post.  For ease of reading, feedback has been synthesized. Full feedback is available for review in the anonymized form responses and comments to the original post.

Please remember that the following feedback are suggestions to bear in mind for future releases rather than action items for implementation. 

What would you keep?

• The Community needs/“wishlist.”
• Blogblog (versus network, site) post per new feature or major change, e.g., performance improvements or the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Tag processor. 
• Release team formation and announcement during the previous release cycle for easy coordination.
• A 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/. channel per release focus.
• Having a co-lead per release focus to allow for complimentary time-zone coverage. 
• Weekly health checks.

What would you add?

• Additional minor releases between majors. 
• Iteration on Twenty Twenty-Four for Twenty Twenty-Five to reduce fragmentation. 
• Earlier merging of stable 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 into WordPress 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.. 
• Equal focus on old tickets and 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 with new features.
• Feature the Pattern Directory in 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.
• A dedicated session in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for testing the release. 
• A focus on cohort involvement for sustained contribution beyond 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.’s development cycle. 
• More underrepresented release squads and opportunities for synchronous meetings in different time zones. 

What would you remove? 

• Underrepresented release squads. 
• Minimum Core code contribution for Editor Tech role.
• Increased documentation and training for new contributors to the release process.
• Allow only “blessed tasks,” with enhancements/features that have received a first commit before 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 to continue to Beta 2 et al.

How did the collaboration feel?

This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.

Would you like to be part of future release squads?

• 16.7%: I haven’t been part of the squad but I would like to try in the future.
• 8.3%: I have been part of a release squad and I will gladly repeat.
• 41.5%: I have been part of a release squad before and will do so again, although maybe not next year.
• 8.3%: I am reluctant to participate again, but I would be open to it if responsibilities and processes were clearer.
• 8.3%: Maybe later, I’m not sufficiently experienced yet.
• 8.3%: I have been part of a release squad and would like to repeat, but unfortunately I don’t have the time for near/midterm future.

Takeaways and next steps

• Respondents felt that following the development cycle as a new contributor was challenging.
  • Future WordPress Contributor Mentorship programs will mirror major releases so new contributors have mentored experience with ample documentation and support to find contribution onboarding opportunities.
• The shorter development cycle, while previously requested, felt too short for ample feature development and testing.
  • The proposed 2024 roadmap allows for extended development cycles.
• 6.4 was, for all intents and purposes, a success in bringing underrepresented gender voices, skill sets, and points of view into WordPress’s development cycle. 2024 will not include specific release squads to allow for more broad contributor involvement.
• Maintenance will be one focus alongside new features for the WordPress 6.6 release in response to a call for more maintenance in major releases. 

Props to @priethor and @chanthaboune for reviewing this post. 

#6-4, #retrospective