Recap: WordPress 6.9 “Gene” Retrospective

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

• Having two triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. leads in different parts of the globe seemed to work well getting more contributors involved.
• Clearer test instructions.
• Long-term planning, regular check-ins, commit freeze, and a consistent cadence made the release feel stable and well-managed.

What would you add?

• More automation for defined, common steps within the release cycle could help reduce stress.
• Better documentation for the tasks required by the different release leads.
• More community suggestions into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
• Earlier on boarding for release squad members.

What would you change, reduce, or remove?

• Release Candidates should be tested more extensively.
• Points of contact and ownership should be more clear, especially for new contributors.
• Reduce manual work by increasing automation where possible.

What else would you like to express about any part of the release cycle or release squad?

• The 6.9 release was well coordinated despite its size and complexity, reflecting significant effort from contributors and release leads.
• There is a need for better communication with teams indirectly involved with the release, especially Documentation.
• Releasing during a major event (SOTW in this case) was exciting but can limit who is able to take part due to various logistical factors (travel funds, VISAs, time differences, etc). Also requires planning further in advance.
• The release squad was highly collaborative. Leads were trusted to complete the work required of their role.
• Lots of contributors and committers were around and made themselves available to answer any questions the squad members had.
• Tracking and guiding all release-related activity across TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and 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/ is a huge undertaking due to the volume of activity. This can place a lot of strain on the team.

Did you have an official role on the release squad during the 6.9 release?

This section describes if the survey participants are part of release squad or observer.

Did you contribute to the 6.9 release?

This section describes if the participants actually contributed to 6.9 release or not.

How did collaborating on this project 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?

• 17.6%: I haven’t been part of a release squad and currently have no interest in it.
• 11.8%: I haven’t been part of a squad but I would like to try in the future.
• 5.9%: I have been part of a release squad but will not repeat in the near future.
• 67.4%: I have been part of a release squad and I will gladly repeat

What is your feedback on the current release squad size?

Takeaways and next steps

• Find ways to assemble and onboard a squad for the next release earlier.
• Review the Core Handbook for missing documentation.
• Figure out how to make responsibilities for release-related tasks more clear.
• Investigate how parts of the release process could possibly be automated.
• Find new ways to encourage wider testing during the 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./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). period.
• Make it more clear which contributors are knowledgeable and available to help for specific tasks or areas of the project.
• Pairing up an experienced and inexperienced contributor in each role is a good way to “level up” those who are looking to participate in a release squad for the first time.

Props to @akshayar & @desrosj for compiling responses, authoring, and @jeffpaul, @jorbin for reviewing this post. 

#6-9, #retrospective