Tag Archives: retrospective

Akshaya Rane 9:33 am on January 23, 2026
Tags: , retrospective   

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

Akshaya Rane 2:12 pm on December 19, 2025
Tags: , , retrospective   

WordPress 6.9 Release Retrospective

Congratulations to all who helped make WordPress 6.9 possible!

Now that the release cycle is complete, you’re invited to reflect and share your thoughts on the release cycle, release processes, release squad, or whatever else is on your mind. Feedback loops are critical to learning what works and what doesn’t so that the teams involved can iterate on the processes to improve for future releases. 

Everyone is welcome to submit feedback about the release using this form, even contributors who did not contribute directly to the release itself.

A member of the community that casually observes a release cycle will have very different thoughts and opinions than someone who was heavily involved on a weekly or daily basis. The more viewpoints and backgrounds represented within this feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. the better. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous, but anything submitted will be anonymized before being shared in a post summarizing the results. Your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is required just case the person processing the responses needs to reach out to you for further clarification.

The form and comments will be open until January 15, 2026. A follow-up post with the collected, anonymized results will be published shortly after.

Again, thank you for your contributions to 6.9 “Gene,” and for taking the time to provide valuable feedback to help make future releases even better!

Props to @amykamala, @desrosj for the peer review.

#6-9, #release-process, #retrospective

David Baumwald 4:53 pm on March 3, 2025
Tags: , retrospective   

Recap: WordPress 6.7 “Rollins” Retrospective

[Editor’s note: This survey was only answered by 3 people, only 2 of which were on the release squad. It’s useful as seeing three people’s distinct opinion, but not extrapolation.]

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

  • Aligning Dev Chats to the time where Tech Release leads could attend was useful and should be considered in the future.
  • Release process.

What would you add?

  • Future release leads should be announced earlier—prior to the end of the previous release.
  • More robust testing around new features in conjunction with plugins.

What would you change, reduce, or remove?

  • The squad was announced too late.
  • The climate of contributing.

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?

What is your feedback on the current release squad size?

Takeaways and next steps

  • One lead felt they and their co-leads were not appropriately respected by a sponsored non-lead and indicated their intent to not volunteer for another lead role without assurances that lead roles are to be respect by non-leads.
  • Another contributor indicated a general sense that release testing throughout the cycle was less that usual.

Props to @desrosj and @jeffpaul for reviewing this post. 

#6-7, #retrospective

David Baumwald 2:11 pm on December 6, 2024
Tags: , , , retrospective   

WordPress 6.7 Release Retrospective

Congratulations to all who helped make WordPress 6.7! Now that it has launched, you’re invited to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases. 

Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.

The form and comments will be open until January 13, 2025. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.

Again, thank you for your contributions to 6.7 “Rollins,” and for taking the time to help make future releases even better!

Props to @priethor for the peer review

#6-7 #retrospective

#core, #release-process

Akshaya Rane 1:09 am on May 8, 2024
Tags: , retrospective   

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.

Forms response chart. Question title: How did collaborating on this project feel?. Number of responses: .

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?

Forms response chart. Question title: What is your feedback on the current release squad size?. Number of responses: .

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

Héctor Prieto 6:07 pm on April 12, 2024
Tags: , , , retrospective   

WordPress 6.5 Release Retrospective

Congratulations to all who helped make WordPress 6.5! Now that it has launched, I invite you to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases. 

Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.

The form and comments will be open until April 26th, 2024. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.

Again, thank you for your contributions to 6.5 “Regina,” and for taking the time to help make future releases even better!

Props to @akshayar and @marybaum for the peer review

#6-5 #retrospective

#core, #release-process

Chloe Bringmann 4:37 pm on December 5, 2023
Tags: , retrospective   

Recap: WordPress 6.4 “Shirley” Retrospective 

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

What would you add?

  • Additional minor releases between majors. 
  • Iteration on Twenty Twenty-Four for Twenty Twenty-Five to reduce fragmentation. 
  • Earlier merging of stable 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/ features into WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.. 
  • Equal focus on old tickets and 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. fixes with new features.
  • Feature the Pattern Directory in the BlockBlock 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.
  • A dedicated session in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for testing the release. 
  • A focus on cohort involvement for sustained contribution beyond a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.’s development cycle. 
  • More underrepresented release squads and opportunities for synchronous meetings in different time zones. 

What would you remove? 

  • Underrepresented release squads. 
  • Minimum Core code contribution for Editor Tech role.
  • Increased documentation and training for new contributors to the release process.
  • Allow only “blessed tasks,” with enhancements/features that have received a first commit before 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 to continue to Beta 2 et al.

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?

  • 16.7%: I haven’t been part of the squad but I would like to try in the future.
  • 8.3%: I have been part of a release squad and I will gladly repeat.
  • 41.5%: I have been part of a release squad before and will do so again, although maybe not next year.
  • 8.3%: I am reluctant to participate again, but I would be open to it if responsibilities and processes were clearer.
  • 8.3%: Maybe later, I’m not sufficiently experienced yet.
  • 8.3%: I have been part of a release squad and would like to repeat, but unfortunately I don’t have the time for near/midterm future.

Takeaways and next steps

  • Respondents felt that following the development cycle as a new contributor was challenging.
    • Future WordPress Contributor Mentorship programs will mirror major releases so new contributors have mentored experience with ample documentation and support to find contribution onboarding opportunities.
  • The shorter development cycle, while previously requested, felt too short for ample feature development and testing.
  • 6.4 was, for all intents and purposes, a success in bringing underrepresented gender voices, skill sets, and points of view into WordPress’s development cycle. 2024 will not include specific release squads to allow for more broad contributor involvement.
  • Maintenance will be one focus alongside new features for the WordPress 6.6 release in response to a call for more maintenance in major releases. 

Props to @priethor and @chanthaboune for reviewing this post. 

#6-4, #retrospective

Chloe Bringmann 8:57 pm on November 15, 2023
Tags: , retrospective   

WordPress 6.4 Retrospective

Congratulations to all who helped make WordPress 6.4 available! Now that it has been successfully released, I invite all who contributed to reflect and share our thoughts on the release process to learn, iterate, and improve for future releases. 

Anyone is welcome to participate in this retrospective, so please take a few moments to complete the form or leave public feedback in the comments below. The survey is not anonymous, allowing for outreach should further clarification be needed; please note that your email address will not be shared or used for any other purpose.

The form and comments will be open until November 30th, 2023, with anonymized results available in a follow-up post in December 2023.

Again, thank you for your contributions to 6.4 “Shirley,” and for taking the time to help make future releases even better!

Props to @priethor and @chanthaboune for the peer review

#6-4 #retrospective

Héctor Prieto 7:37 pm on April 14, 2023
Tags: , retrospective   

WordPress 6.2 “Dolphy” Retrospective

With WordPress 6.2 released and available to the world, it would be very helpful to this and future release squads if all those who contributed could take the time to reflect and share thoughts on the release process to learn, iterate, and make future releases smoother. ✨

Anyone is welcome to participate in this retro, so please take a few moments to complete the form or leave public feedback in the comments below. The survey is not anonymous, allowing for outreach should further clarification be needed; please note that your email address will not be shared or used for any other purpose.

The form and comments will be open until April 30th, 2023, with anonymized results available in a follow-up post in May 2023.

Thank you, everyone, for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!

Props to @cbringmann, @chanthaboune for the peer review

#6-2 #retrospective

Héctor Prieto 7:36 pm on April 14, 2023
Tags: , retrospective   

Recap: WordPress 6.1 “Misha” Retrospective

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.
  • 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.
  • 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