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

1. What would you keep?
2. What would you add?
3. What would you change, reduce, or remove?
4. What else would you like to express about any part of the release cycle or release squad?
5. Did you have an official role on the release squad during the 7.1 release?
6. Did you contribute to the 7.1 release?
7. How did collaborating on this project feel?
8. Would you like to be part of future release squads?
9. What is your feedback on the current release squad size?
10. Takeaways and next steps

• The usual release parties and weekly check-in rituals.
• Good communication throughout the release cycle, including security updates.
• Security auditing, including handling all known high-risk HackerOne issues before deploy Launching code from a local development environment to the production web server, so that it's available to visitors..
• Task lists for every role.

• A kick-off call for the release squad, which helped the group work together and could be continued when time zones allow.
• More emphasis on user documentation and on completing it on time.
• Earlier visibility into user-facing block 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 UI User interface changes. Some changes, such as the Elements panel and the GIF video block variation, were mainly documented in dev notes 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. or GitHub 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 by the repository owner. https://github.com/ PRs, which made it harder for documentation contributors and for people supporting site editors to prepare.
• Developers marking their tickets for dev notes or the field 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. where appropriate, and writing their own dev notes.
• Wider testing, for example by inviting hosts to test in their own environments and providing them with AI prompts to use on their setups.

• Launching live at an event. One respondent felt it was not worth the added stress, and other members of the release squad agreed. If a release is tied to an event again, it helps when everyone involved follows the agreed schedule and arrangements during the event.
• Better time zone overlap among release squad members where possible.
• A request to bring back the official Docs role. Documentation work during a release is substantial, and only a few contributors currently have the experience to cover it.
• More Learn content related to the release.

• More contributors who can follow many parts of the project at once would help. This gap was noticeable in several places during the cycle.
• More awareness of concerns in the plugin 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. and theme ecosystem.
• More automation, given how often the release process has been carried out.
• The release squad communicated thoughtfully and was open to feedback, and respondents thanked the squad for their work.

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

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

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

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

• Consider the impact before tying a release to a live event, and agree early on a schedule that everyone involved can follow.
• Continue holding a kick-off call for the release squad, and consider time zone overlap when assembling the squad.
• Find ways to share user-facing editor UI changes earlier with documentation and support contributors.
• Encourage developers to mark tickets for dev notes or the field guide and to write their own dev notes.
• Investigate which parts of the release process could be automated.
• Find new ways to encourage wider testing during the beta 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. and RC 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, for example together with hosts.
• Make it clearer which contributors can follow many parts of the project and are available to help with specific areas.
• Look at ways to connect more Learn content to each release.
• Find ways to raise awareness of concerns from the plugin and theme ecosystem during the cycle.

Props to @annezazu for reviewing this post. 

#7-1, #retrospective