WordPress 6.0 Retrospective Recap

This post seeks to summarize the feedback received from the 6.0 retrospective, shared on May 27th. Thank you to the eight people who took the time to share their feedback and to those who also did so publicly on the post itself. To keep the post succinct, some non-actionable feedback has been consolidated. 

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

What would you keep?

Outside of the following, there were repeat mentions of how collaborative, kind, and communicative the squad was as a whole in answering pings, making decisions, and supporting each other. 

• Early sharing of the feature highlight grid to influence About page, release video, etc. 
• Weekly check-ins.
• Dedicated release channel for coordination.
• Redundancy with co-leads in various roles to allow for more focus on details, higher capacity for work, etc. 
• Lack of heroic efforts and last-minute dashes
• Collaborative decision making, e.g. with regard to the WebFonts 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.
• Structured release parties 

What would you add?

• More support for Docs & Training resources, matching devs that worked on issues with those writing docs/training.
• Clearer documentation around resolving tricky issues during a release and when to bring leadership in.
• Consider having apprenticeship roles for release squad roles to create a backup and for the continuity of the project. 
• A reimagined About page that designers can build directly using blocks.
• Improved automations, specifically for the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Lead role. 
• Release squad should be picked as early in the release process as possible to allow time to prepare.
• Consider adding documentation lead role for End User documentation 
• Improve process for identifying items that need dev notesdev 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., including labeling of PRs that need dev notes, considering multiple types of flags (DevNotedev 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. / MiscDevNote / 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.), ensuring documentation is in place for what needs dev notes, and implementing automation to collect all items. 
• Checklist for each member of the squad at each release phase for improved coordination. 

What would you remove?

• Confusion/concerns around the Webfonts API situation. 
• Confusion around the initial 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 post and what role everyone played. This was very quickly resolved. 
• Backporting months worth of 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/ PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher changes before the release. 
• Lack of decisions and process around stabilizing and introducing experimental APIs, leading to a backlog.
• Improving the process of introducing, stabilizing, and phasing.
• Secrecy around jazzer leading to a lot of complexity around release time.
• Too many places for tracking documentation updates from the docs team.
• Complicated process for dev notes, including recommendations to stop using comments on the 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/ DevNote tracking issue for collecting all dev notes and change deadline to Beta 1 to give docs team more time.
• Implementing a feature freeze in Gutenberg a week earlier to leave more room for integration with WordPress Core and reduce the length of beta releases.
• Share more marcoms around the behind the scenes work with performance and 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) so the UIUI User interface changes aren’t over indexed on messaging wise. 

How did the collaboration feel?

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

Collaborating on this release was easy results

Collaborating on this release was enjoyable results

Collaborating on this release was efficient results

Collaborating on this release was well organized results

The release process was transparent and easy to follow

Would you like to be a part of future squads?

87.5% of people said “I have been part of the release squad and I will gladly repeat”. 12.5% of people said “I haven’t been part of the squad but I would like to try in the future”.

Next Steps

At a high level, a few discussions and follows up have already occurred that others can participate in: 

• A follow up post was done since the retrospective sharing improvements and automations for the Core Editor release role in light of the experience of those this release cycle. 
• An open discussion is underway around how best to 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. PHP changes. 
• An open discussion is underway on the topic of improving ad clearing part of the backlog for experimental APIs. 

Outside of the above, it’s clear that there are some process improvements particularly around documentation to consider including a role for End User documentation, changing the way documentation updates are tracked across multiple places, and the way in which dev notes are wrangled. 

---

If you are interested in being a part of 6.1’s release squad and working to improve the experience, please share in the comments of the 6.1 planning post. 

Thank you to @davidb @zieladam for reviewing.

#6-0, #retrospective