Recap: WordPress 6.5 “Regina” Retrospective

This post summarizes the feedback received from the WordPress 6.5 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?

• More than one Editor tech lead
• 24-hour Comitter freeze before the release party
• Run the release party by release coordinators

What would you add?

• A lead dev, specifically identified for each feature project. More lead dev or coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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. feedback for feature projects 
• Transparency of “leadership” decisions.
• Increase in our release cadence. Docs lead & design team collaboration increase for Dev notedev note Each 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. & Field GuideField guide The 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.. A field guide can be made simpler as 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/ releases updates posts. 
• Form the upcoming release squad early. Provide heads-up to selected squad members before x.y Release squad post gets published. Also, Allow them to set the Roadmap.
• Improve Gutenberg feature merges into Core. If a feature satisfies the MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia, include it; half-baked features should wait until they, too, work at the MVP level. 
• Automate some parts of the Release process to avoid errors & reduce release party time.

What would you change, reduce, or remove?

• Sync GB packages more often. Make Gutenberg follow the same rules as TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for commit.  
• Document Release LeadRelease Lead The community member ultimately responsible for the Release. role rights. The person should:
  • Give the squad a clear vision/structure. 
  • Be the final arbiter of what gets included or punted from a release.
  • In the absence of a release lead, clearly delegate that responsibility to other roles.
• Include the Theme Wrangler role in the Squad if major changes will come to themes (and not otherwise).
• Publish major feature architecture early, to accommodate changes easily. 
• Improve the release-process documentation to include communication with other teams. For example:
  • Notify Theme Wrangler to work on changes that impact Default themes.
  • Collaborate with Themes and Plugins teams to keep extenders aware of breaking changes and other docs they need to prepare for the release. At the moment, this consists mostly of an email to pluginPlugin A 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 developers and, lately, one to theme authors, 
• We need to be better at sticking to feature deadlines for releases. Update Project philosophies to include exception criteria for Release delay. 
• The “Source of Truth” post that Anne publishes for each release is super helpful. If we can make it a process to publish this on make/core, it will save a lot of duplicated effort. It will also give the Marketing/Media Relations, Docs and Training better information and more time to get the wider ecosystem prepared for new features.

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?

• 11.1%: I haven’t been part of the squad but I would like to try in the future.
• 66.7%: I have been part of a release squad and I will gladly repeat.
• 0%: I have been part of the release squad but will not repeat in the near future
• 0%: I haven’t been part of the squad but I would like to try in the future
• 11.1%: Day job doesn’t allow for the consistent time.
• 11.1%: I have been part of a release squad and I will repeat, However perhaps in some time. 

What is your feedback on the current release squad size?

Takeaways and next steps

• Several very long-term contributors mentioned that the current process for adding new editor features diverges significantly from traditional processes, and they found it hard to influence direction before those features incurred predictable consequences.
• The fixes they propose echo those of other respondents:
  • More frequent syncing of the editor package to the wordpress-dev repo
  • More posts on Make that highlight important discussions on the Gutenberg repo
• Contributors across the board would like to see more communication with extenders about new features and breaking changes.
• Contributors value the Source of Truth documentation that comes from Anne McCarthy and have come to rely on it.
• That said, they would like information about new features even more often, earlier, and in more media.
• Contributors would also like more information on the roles of release leads (not just coordinators) and what decisions the lead makes versus what decisions are the purview of the tech leads.
• Finally, respondents would like to see updates in the Handbook that specify what issues can legitimately delay a release and that a squad will follow the principle that deadlines are not arbitrary the rest of the time.

Props to @priethor,@marybaum and @akshayar for compiling retrospective responses & reviewing this post. 

#6-5, #retrospective