This post summarizes the feedback received from the WordPress 6.1 retrospective. Due to an error in the form linked in the original retrospective post, the results of the retrospective are shared later than anticipated, and your patience is appreciated.

Thank you to the people who took the time to share their feedback and those who did so publicly on the post itself. To keep this post succinct, some feedback has been consolidated; you can check the anonymized form responses and the comments section in the retrospective announcement for the full feedback.

Please remember that these are just suggestions and things to consider for the future rather than items that will be implemented later. 

What would you keep?

• The release leads 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.
• Weeklies, 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. scrubs, and editor PR triages.
• Having several Editor-related leads.
• Focusing on non-editor areas like performance, accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), and developer experience.
• The release cycle length, as opposed to the original shorter one proposed.
• The product walkthrough continues to be a valued addition.
• The less “strict” process than previous releases allowed contributors to work on many things they wouldn’t have had the opportunity to work on otherwise.
• Collaboration across different teams seemed to work well.

What would you add?

• More transparency in coordination, governance, and decision-making in public spaces.
• Improving and automating the backporting of editor features to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
• An earlier cut-off for new Editor features and Enhancements to prevent last-minute fixes due to unstable code from 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/.
• Backporting from Gutenberg in smaller chunks to reduce the effort necessary to find the exact cause of bugs due to the large, multi-commit PRs.
• Requiring any new Editor code to first go through a public release in the Gutenberg 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. before being considered for merging into Core.
• Requiring the use of the new “private exports” code for any “experimental” or “unstable” Editor APIs that are consumed by Core.
• Making all the data from this Retrospective public.
• A more complete and timely roadmap.
• Attention to other non-Gutenberg components, and polishing the Gutenberg APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
• A more effective way of gathering feedback than the retrospective form allows.
• There were 3 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). rushed in the last week of release, and the final RC 6 was released a day before the actual release date. The final RC was reverting some changes: in these cases, an extended code freeze would allow sufficient time for the themes and plugins to get their code compatible with WordPress.
• An even bigger focus in the performance area.
• More people doing code reviews.
• Earlier ticketticket Created for both bug reports and feature development on the bug tracker. scrubbing in the release build cycle to avoid delaying the release parties.
• More folks to oversee the Editor tasks/PRs; Gutenberg is too big for even a group of 5-6 folks to oversee and catch every issue completely.
• Considering National holidays in Major countries. The auto-update broke some of the sites that used specific plugins during a major EU holiday.

What would you remove?

• Work done in non-public channels to avoid making non-sponsored contributors feeling not really valued.
• The manual backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. process from Gutenberg to Core.
• The “Walkthrough”.This started as a “Go, No-go” but failed at its designed purpose to provide a line in the sand for feature inclusion based on a thorough, early review session. This was changed to “Walkthrough” to make it seem like it wasn’t an absolute statement on what will or will not be included in the final release. However, this “Walkthrough” only increases the pressure on contributors to essentially “follow the roadmap” of what is expected by leadership after the Walkthrough is made public. Removing it would let contributors offer an unpressured evaluation of new features before release to determine if they are actually ready for inclusion.
• Weekly check-ins.`@`ing every single person on the squad is helpful; a more generic `@channel` call asking for anyone with flags to raise them would be better.
• The shift from summarizing updates in meetings to relying on dozens of async updates.

How did the collaboration feel?

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

Some takeaways and next steps

There were various recurring topics that have experienced changes in the WordPress 6.2 release cycle. Please make sure to add your updated feedback to the 6.2 retrospective!

• Most respondents felt the process was not transparent enough, with many decisions being made in private spaces.
  • The WordPress 6.2 release squad has made an effort to bring as many conversations as possible to the #6-2-release-leads Slack channel.
• There are discrepancies around the usefulness of the walkthrough, especially its purpose.
  • In WordPress 6.2, the format iterated once again from Go/No Go to Walkthrough to a Live Demo, closer to the final release and showing a more polished product, instead of setting expectations that could result in pressure for contributors to meet the target.
• Backporting from the Gutenberg repository to core still is a pain point.
  • As this is a recurring topic, earlier, smaller backports happened during 6.2.
• Respondents suggested an even bigger focus in the performance area.
  • WordPress 6.2 included a new Performance Lead role in its squad.
• Inefficient weekly check-ins with the release squad.
  • Based on this early feedback, the 6.2 release cycle saw a shift: release coordinators didn’t pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” individual release leads, and limited to listing the release areas during check-ins.
• A more effective way of gathering feedback than the retrospective form allows.
  • Although there is no indication of what a more effective way of gathering feedback would look like, the 6.2 retrospective includes more open-ended questions.
• Requiring the use of the new “private exports” code for any “experimental” or “unstable”.
  • Thanks to Private and Plugin-only APIs, Experimental APIs in WordPress core have largely been tamed. A follow-up post on this topic will be published here in make/core next week. Stay tuned! EDIT April 17th: the post is live now.
• Making all the data from this Retrospective public.
  • As commented at the intro of this post, here it is 🙂

Props to @cbringmann, @chanthaboune for reviewing this post.

#6-1 #retrospective