Tag Archives: 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

Héctor Prieto 7:14 pm on November 9, 2022
Tags: , retrospective   

WordPress 6.1 ‘Misha’ Retrospective

With WordPress 6.1 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our 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 fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.

The form and comments will be open until December 15th, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog (versus network, site) in January 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 @desrosj for peer review

#6-1 #retrospective

annezazu 7:28 pm on July 7, 2022
Tags: , retrospective   

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 7.4 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 by 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

Pie chart showing that 62.5% of people strongly agree, 25% slightly agree, and 12.5% slightly disagree that collaborating was easy.

Collaborating on this release was enjoyable results

Pie chart showing that 75% of people strongly agree and 25% slightly agree that collaborating was enjoyable.

Collaborating on this release was efficient results

Pie chart showing that 50% of people strongly agree, 12.5% slightly agree, and 37.5% slightly disagree that collaborating was efficient.

Collaborating on this release was well organized results

Pie chart showing that 50% of people strongly agree, 37.5% slightly agree, and 12.5% slightly disagree that collaborating was well organized.

The release process was transparent and easy to follow

Pie chart showing that 37.5% of people strongly agree, 37.5% slightly agree, and 25% were neutral that 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.

Untrash<\/a><\/li><\/ul><\/nav>","mentions":["annezazu"],"mentionContext":"","commentCreated":"1657250789","hasChildren":false,"userLogin":"chaion07","userNicename":"chaion07"},{"type":"comment","id":"43342","postID":"97477","postTitleRaw":"WordPress 6.0 Retrospective Recap","cssClasses":"comment byuser comment-author-zieladam odd alt thread-even depth-1","parentID":"0","contentRaw":"That's a great summary @annezazu, thank you so much for sharing it!","contentFiltered":"

That\u2019s a great summary Untrash<\/a><\/li><\/ul><\/nav>","mentions":["annezazu"],"mentionContext":"","commentCreated":"1657265579","hasChildren":false,"userLogin":"zieladam","userNicename":"zieladam"},{"type":"comment","id":"43343","postID":"97477","postTitleRaw":"WordPress 6.0 Retrospective Recap","cssClasses":"comment byuser comment-author-priethor even thread-odd thread-alt depth-1","parentID":"0","contentRaw":"Awesome summary, thanks for compiling it @annezazu!!","contentFiltered":"

Awesome summary, thanks for compiling it Untrash<\/a><\/li><\/ul><\/nav>","mentions":["annezazu"],"mentionContext":"","commentCreated":"1657299271","hasChildren":false,"userLogin":"priethor","userNicename":"priethor"},{"type":"comment","id":"43353","postID":"97477","postTitleRaw":"WordPress 6.0 Retrospective Recap","cssClasses":"comment byuser comment-author-dansoschin odd alt thread-even depth-1","parentID":"0","contentRaw":"Just reiterating what a great honor and experience it was to be part of this release squad and I would gladly go it again. I have also gathered a bunch of resources that I will organize and share publicly in due course with regards to the mar\/comms role to assist future squad leads in that specific role.","contentFiltered":"

Just reiterating what a great honor and experience it was to be part of this release squad and I would gladly go it again. I have also gathered a bunch of resources that I will organize and share publicly in due course with regards to the mar\/comms role to assist future squad leads in that specific role.<\/p>\n","permalink":"https:\/\/make.wordpress.org\/core\/2022\/07\/07\/wordpress-6-0-retrospective-recap\/#comment-43353","unixtime":1657654735,"loginRedirectURL":"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2022%2F07%2F07%2Fwordpress-6-0-retrospective-recap%2F%23comment-43353&locale=en_US","approved":true,"isTrashed":false,"prevDeleted":"","editURL":null,"depth":1,"commentDropdownActions":"","commentFooterActions":"","commentTrashedActions":"

Héctor Prieto 11:15 am on May 27, 2022
Tags: , retrospective   

WordPress 6.0 ‘Arturo’ Retrospective

With WordPress 6.0 out in the world, it would be very helpful to this and future release squads if all those involved in contributing could take some time to reflect and share our 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 fill in the form or leave public feedback in the comments below. The survey is not anonymous if I need to reach out for further clarification, but your email address will not be shared or used for any other purpose.

To accommodate for WCEU2022 taking place next week,  the form and comments will be open until June 19, 2022. The results will be reviewed and summarized in a follow-up post in this same blogblog (versus network, site) in late June 2022.

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 @annezazu for peer review

#6-0 #retrospective

Tonya Mork 9:38 pm on January 27, 2022
Tags: , retrospective   

WordPress 5.9 ‘Joséphine’ Retrospective

Having fully celebrated the release of 5.9, but before turning focus to 6.0, it would be helpful to this and future squads if all those involved in contributing to 5.9 could take a few moments to share your thoughts about the release process.

Taking the pulse in the form of a retrospective helps to:

  • Discover the things the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team finds valuable to keep doing in future releases because they were a positive experience and moved the project forward.
  • Help identify areas that were not helpful in fulfilling release goals or were not positive for people participating.

All feedback is valuable to help to continuously improve the release process.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

~ Norm Kerth, Project Retrospectives: A Handbook for Team Review

Anyone is welcome to participate in this retro. Please take a few moments to fill in the form or leave public feedback in the comments below.  The form will be open until February 14, 2022.

Please note, the form is not anonymous as it asks for your email address. Your email will only be used for follow-up questions and will not be used for any marketing or other purposes.

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

Props to @audrasjb for peer review.

Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1643321669","hasChildren":false,"userLogin":"davidbaumwald","userNicename":"davidbaumwald"},{"type":"comment","id":"42493","postID":"94012","postTitleRaw":"WordPress 5.9 \u2018Jos\u00e9phine\u2019 Retrospective","cssClasses":"comment byuser comment-author-mte90 even thread-even depth-1","parentID":"0","contentRaw":"My thoughts on 5.9 is that also if WordPress get to freeze for new stuff Gutenberg it isn't and to me lead to delay of this release. With all the burn-out for this change of the last minute for a pull request in Gutenberg.\nAn example of people tired of this way to manage the development process: https:\/\/twitter.com\/Mte90Net\/status\/1487084641517514755\n\nI like a more long release, as in Open Source usually stuff is released when it is ready and not by dates.\nFrom the other side I see that in the last years is always more difficult to get address bug tickets on WP (not gutenberg ones) and to me, they should get priority as it is clear that Gutenberg follows a different management that doesn't work with the WP ones.\n\nPS: I was thinking to abandon to contribute to WP for patches a lot of times, but I'm still doing because there are old patches still waiting for a review, and sometimes my customers had issues, so I work on a patch to fix it. But if I could choose, I will abandon totally to contribute to WP core as it is not worth it.","contentFiltered":"

My thoughts on 5.9 is that also if WordPress get to freeze for new stuff GutenbergGutenberg<\/span> 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 \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.
\nUntrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1643456527","hasChildren":false,"userLogin":"Mte90","userNicename":"mte90"},{"type":"comment","id":"42498","postID":"94012","postTitleRaw":"WordPress 5.9 \u2018Jos\u00e9phine\u2019 Retrospective","cssClasses":"comment byuser comment-author-talldanwp odd alt depth-2","parentID":"42479","contentRaw":"Similar thoughts here about the Go\/No-go meeting. Perhaps a second meeting was required before the beta period, just to make sure the 'next steps' outlined in that post were all completed to a satisfactory level.\n\nThis was a particularly big release, so it's possible the processes that worked well on previous releases weren't as effective because of that.","contentFiltered":"

Similar thoughts here about the Go\/No-go meeting. Perhaps a second meeting was required before the betaBeta<\/span> 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.<\/span><\/span><\/span> period, just to make sure the \u2018next steps\u2019 outlined in that post were all completed to a satisfactory level.<\/p>\n

This was a particularly big release, so it\u2019s possible the processes that worked well on previous releases weren\u2019t as effective because of that.<\/p>\n","permalink":"https:\/\/make.wordpress.org\/core\/2022\/01\/27\/wordpress-5-9-simone-retrospective\/#comment-42498","unixtime":1643614907,"loginRedirectURL":"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2022%2F01%2F27%2Fwordpress-5-9-simone-retrospective%2F%23comment-42498&locale=en_US","approved":true,"isTrashed":false,"prevDeleted":"","editURL":null,"depth":2,"commentDropdownActions":"","commentFooterActions":"","commentTrashedActions":"

Josepha 8:56 pm on July 28, 2021
Tags: , retrospective   

WordPress 5.8 ‘Tatum’ Retrospective

A lot of things changed with the way that the WordPress 5.8 release was managed. A retrospective is always a good idea after a project, but in this case I wanted to be sure I cataloged the big changes for anyone who felt that it was different, but couldn’t quite put words to it. I originally shared this with the release team in Slack.

  • The teamwork had a different feeling. Instead of having buddies or cohorts of learning contributors (roughly one-to-one), we put the squad in a public channel to coordinate the work (one-to-many).
  • The release process had a different feeling. We made feature freeze independent of any other type of milestone and also are trying to be more focused about what work is done in each phase.
  • The included features had a different feeling. Instead of flipping the switch on a massive change for everyone, full site editing is being being shipped in smaller, more manageable chunks so it’s easier to catch up and we can iterate as we go.
  • The environment is different. We’ve all been struggling through this pandemic and being isolated from those we care for. Whether we recognize it or not, that has a profound impact on what we choose to do with our spare time, how we are able to meet others where they are, and whether we “grow through” or “bounce back” from hurdles that stand in our way.

Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. It is not anonymous in case I need some clarification, but your email address will not be kept. The form will be open until August 15, 2021.

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

Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1627654514","hasChildren":false,"userLogin":"youknowriad","userNicename":"youknowriad"},{"type":"comment","id":"41665","postID":"90352","postTitleRaw":"WordPress 5.8 \u2018Tatum\u2019 Retrospective","cssClasses":"comment byuser comment-author-gziolo even depth-2","parentID":"41659","contentRaw":"Thank you for sharing your feedback Riad. I can respond to the part related to the process of backporting PHP changes from the Gutenberg plugin to WordPress core that I helped with. It's the biggest pain point at the moment that needs major refinements. The current structure of the Gutenberg plugin makes it really hard to locate the changes necessary to bring to WordPress core together with related JavaScript logic. Before anything else, we should make it more transparent in the plugin what's already in WordPress core, what's ready to be backported, and what's still an experiment. \n\nIn addition to the challenges with identifying PHP changes that should be moved to the WordPress core from the plugin there were other related issues:\n- the same functions\/classes used in the plugin and WordPress core, weren't properly guarded in the plugin triggering redeclaration errors \n- the name of the functions\/methods were too general in the context of WP core \u2013 it's something that could be caught earlier in the PR review process\n\nI also opened an issue in Gutenberg: https:\/\/github.com\/WordPress\/gutenberg\/issues\/33810. Let's discuss there more in-depth what changes in the plugin might bring us closer to the semi-automated process of backporting.","contentFiltered":"

Thank you for sharing your feedback Riad. I can respond to the part related to the process of backporting PHPPHP<\/span> The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher<\/span><\/span><\/span> changes from the GutenbergGutenberg<\/span> 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 \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.
\nUntrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1627894931","hasChildren":false,"userLogin":"gziolo","userNicename":"gziolo"},{"type":"comment","id":"41674","postID":"90352","postTitleRaw":"WordPress 5.8 \u2018Tatum\u2019 Retrospective","cssClasses":"comment byuser comment-author-kirasong odd alt thread-even depth-1","parentID":"0","contentRaw":"Hey everyone!\n\nCongrats on the release, and thanks for all your work.\n\nDuring the release, I wanted to note that I found it really helpful for the release leads channel to be public.\n\nI\u2019m not sure how different this felt as a lead, but as a contributor, it was really helpful both to follow release direction, and to know how best to offer help when issues came up \/ what was already taken care of.","contentFiltered":"

Hey everyone!<\/p>\n

Congrats on the release, and thanks for all your work.<\/p>\n

During the release, I wanted to note that I found it really helpful for the release leads channel to be public.<\/p>\n

I\u2019m not sure how different this felt as a lead, but as a contributor, it was really helpful both to follow release direction, and to know how best to offer help when issues came up \/ what was already taken care of.<\/p>\n","permalink":"https:\/\/make.wordpress.org\/core\/2021\/07\/28\/wordpress-5-8-tatum-retrospective\/#comment-41674","unixtime":1627987616,"loginRedirectURL":"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2021%2F07%2F28%2Fwordpress-5-8-tatum-retrospective%2F%23comment-41674&locale=en_US","approved":true,"isTrashed":false,"prevDeleted":"","editURL":null,"depth":1,"commentDropdownActions":"","commentFooterActions":"","commentTrashedActions":"

Dee Teal 12:10 am on December 16, 2020
Tags: , retrospective   

WordPress 5.6 ‘Simone’ Retrospective

Having fully celebrated the release of 5.6, but before turning focus our to 5.7 it would be so helpful to this and future squads, if all those involved in contributing could take a moment to share their thoughts about the process of the release.

Taking the pulse in the form of a retrospective will help uncover things that the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team find valuable to keep doing in future releases because they were a positive experience and moved the project forward in the way we need. It will also help identify areas that were not helpful in fulfilling our goals or were not positive for people participating. So we value all feedback to help us continue to iterate.

To participate in this retro, please take a few moments to fill in this form. It is not anonymous, but your email address will not be kept or used for any other purpose than to discourage trolling.

Thank you one and all for your contribution to this release, and thanks in advance for taking the time to help make future releases even better. Expect the consolidated results to be published early in 2021.

If you prefer, here’s a link to the form embedded below.

(Props to @audrasjb for copy edit suggestions).

#5-6, #retrospective

Francesca Marano 4:12 pm on December 12, 2020
Tags: retrospective   

A year of (subtle) changes

On December 4, 2019, I published a post with a recap of the feedback received for the WordPress 5.3 retrospective. It included a list of “Next Steps”. This post aims to check what was done and what wasn’t.

Done

  • Continue with the release squad model.
  • Mentorship model: focus leads of 5.3 help 5.4 and so on.
  • Make an open call for volunteers. Team reps and previous release leads can nominate people that:
    • Are willing to take part in this.
    • Are a good fit.
  • Add a Design Focus Lead.
  • Add another Documentation Focus Lead to ensure a timely publication of 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. and 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. and facilitate the addition of a “docs-updating” stage.
  • Add a Test Focus Lead.
  • A private channel for the release team. It provides the new focus leads a safe space to learn and ask questions that they might feel intimidated by asking in the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. channel. No decisions are made in the channel.
  • Continue using a sticky post to announce 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 publish in advance the list of bugs that will be tackled.
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. team
  • Avoid introducing new technologies without a prior discussion and/or updating external libraries close to 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.

Work In Progress

  • Write a description for each role involved.
  • Add some tasks to the release coordinator role:
    • 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.” component maintainers and core committers at the beginning of the cycle and every few months to ensure there is a clear picture of availability
    • Ping active component maintainers weekly to give a status report. This could be done in two steps: automated post on the Core blogblog (versus network, site) followed by ad hoc pinging in case of no reply.
    • Office Hours to facilitate cross-team collaboration
  • Rethink the roles of the release to give better credit. Define roles (are they even needed beyond the squad?) and be generous with props.
  • Publish the agenda for the dev chats 24 hours prior to the chat with a more structured model.
  • Call for tickets and component focuses
  • Recap of the above with reasoning behind the decisions taken regarding the features that will be considered
  • Propose schedule, scope, and focus leads at the beginning of the release cycle and publish all the milestones.
  • Communicate the release to a wider audience – Marketing Team
  • Increase the release cadence – Release Model Working group (dormant)

Not addressed

  • Reviewing and updating the release cycle documentation
  • Creation of a TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the make.wordpress.com/marketing team uses for example: https://trello.com/b/8UGHVBu8/wp-marketing. board for birds-eye project management

Next step

Focusing on the low hanging fruits proved to be a good idea, and in fact the above report shows that the smaller the tasks were, the easier they were achived.

I will ping people that are somehow involved with the “Work in Progress” and the “Not addressed” tasks to check what can be done to move them forward or close them.

Thank you all!

#retrospective

Francesca Marano 10:31 am on April 3, 2020
Tags: , retrospective   

5.4 Retrospective – Call for feedback

WordPress 5.4 “Adderley” was released on March 31, 2020.

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

  • What should WordPress start doing as a part of the development process?
  • What should WordPress stop doing as a part of the development process?
  • What should WordPress continue doing as a part of the development process?

Please note that I am looking for feedback specifically on the development and release process.

Please share your thoughts in the comments below! Deadline: April 30, 2020

If you rather not give your feedback in a public space, please reach out to me (@francina) or @davidbaumwald, in 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/. We are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form.

Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1585914608","hasChildren":false,"userLogin":"newyorkerlaura","userNicename":"newyorkerlaura"},{"type":"comment","id":"38361","postID":"80652","postTitleRaw":"5.4 Retrospective \u2013 Call for feedback","cssClasses":"comment byuser comment-author-mte90 odd alt thread-odd thread-alt depth-1","parentID":"0","contentRaw":"In this version I saw more tickets about bugs addressed and fixed since 5.0.\nSo I think that we should continue on review tickets with patches about bugs.\nI got as I can remember 3-4 personal patches approved and this was very thrilling because this doesn't happen usually.\nI hope that in the future here is more attention about bug fixing and not only adding new features (adding new hooks for me is a bug fixing).\nAnother thing we have to continue is doing the refactoring of wordpress and improving the coding standard.\n\nFor me stopping the actual release cycle like every 2-3 months that is very few for who maintain a lot of websites, especially if there are so many new features to test.","contentFiltered":"

In this version I saw more tickets about bugs addressed and fixed since 5.0.
\nSo I think that we should continue on review tickets with patches about bugs.
\nI got as I can remember 3-4 personal patches approved and this was very thrilling because this doesn\u2019t happen usually.
\nI hope that in the future here is more attention about bugbug<\/span> 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.<\/span><\/span><\/span> fixing and not only adding new features (adding new hooksHooks<\/span> In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.<\/span><\/span><\/span> for me is a bug fixing).
\nAnother thing we have to continue is doing the refactoring of wordpress and improving the coding standard.<\/p>\n

For me stopping the actual release cycle like every 2-3 months that is very few for who maintain a lot of websites, especially if there are so many new features to test.<\/p>\n","permalink":"https:\/\/make.wordpress.org\/core\/2020\/04\/03\/5-4-retrospective-call-for-feedback\/#comment-38361","unixtime":1585917480,"loginRedirectURL":"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2020%2F04%2F03%2F5-4-retrospective-call-for-feedback%2F%23comment-38361&locale=en_US","approved":true,"isTrashed":false,"prevDeleted":"","editURL":null,"depth":1,"commentDropdownActions":"","commentFooterActions":"","commentTrashedActions":"

Andrew Ozz 12:54 am on January 8, 2020
Tags: , retrospective   

5.3 Release Cycle Post-mortem

By the Numbers

This cycle was longer, taking just over six months. The development (alpha) stage was 138 days, from May 8 to September 23. During that time there were 779 commits to 5.3 (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.). Most active committers were @SergeyBiryukov with 426 (no surprises there), @pento 66, @afercia and @desrosj with 51 commits each.

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.” stage started on September 23 and lasted for 23 days. There were 274 commits. Most active committers were @SergeyBiryukov with 78, @afercia 42, @desrosj 34, and @whyisjake with 24 commits.

The “release candidaterelease 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).” stage started on October 16 and lasted for 27 days. There were 100 commits including documentation and build tools changes. Most active were @SergeyBiryukov with 39, @desrosj 20, and @johnbillion with 14 commits. There were 30 commits that were merged to the 5.3 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". after it was created on October 29.

In total the release cycle lasted for 188 days and there were 1,153 commits. Looking at the numbers, the busiest time was during beta with an average of nearly 12 commits per day. For comparison there were only about 5.5 commits per day during the “alpha” stage *.

Needed Improvements

There were also some irregularities during the 5.3 cycle.

  • Many “new” bugfixes were committed during beta. Generally these are added in alpha, and beta is reserved for testing and fixing any bugs introduced in alpha.
  • Several apparent enhancements were committed from partially related bugfix tickets: #34904, #47477, #47153, etc. Preferably there would be a discrete 1:1 relationship between tickets and changesets.
  • Some code that would be considered “alpha” (mostly untested and non-reviewed) was committed during beta. Preferably any code committed in beta is well-reviewed by multiple people with varied knowledge/experience with the existing code/areas of expertise.

A substantial departure from past releases was the inclusion of “global” CSSCSS Cascading Style Sheets. changes affecting all of the WordPress adminadmin (and super admin) during beta. They were committed from unrelated or partially related tickets: [46241], [46360], [46244], and most of the other changesets marked as “Improve and modernize user interface controls”.

It would have been preferable for the changes to be separated in new tickets, tested, reviewed, and then committed. Separating these into individual tickets would also have let enhancements be isolated and prepared for the next 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..

Individually, none of the irregularities listed above are a big problem, but when taken all together it introduced avoidable complexity. In this particular case, many small styling bugs were introduced during beta, which is far too late in the release cycle. Again, individually they were fixable, but their late introduction and lack of discrete ticketing left folks without enough time to find and fix them all.

Moving Forward

There are few steps that can be taken to avoid such irregularities in the future:

  • Add some “Release Cycle 101” to the developer documentation. This will ensure that people without prior experience are on the same page. Generally during alpha anything goes. Trunk can be broken and fixed every day as the contributors iterate on enhancements and bugfixes. Beta is for testing by the users and to fix the bugs that were introduced in alpha. 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). is “we think it’s ready, find the edge cases!” 
  • Add a requirement for a code review for all changes committed during beta. Generally this has been the case for most commits during both alpha and beta. Requiring a review before merging works very well in 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/. It’s about time to make it “official” on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. too.
  • Remove the “(blessed)” part from the “task” ticketticket Created for both bug reports and feature development on the bug tracker. type on Trac. It seems it gives the wrong impression that a ticket can be “blessed” by anybody to allow it to bypass the release cycle rules.
  • Restrict use of the “task” ticket type on Trac only to the project leadership. Bypassing (our own) release cycle rules is not something that can be done lightly and carries a lot of responsibilities. Also, perhaps add a requirement for at least two reviews for each commit/code change in this case.
  • Perhaps extend the section on creating and using Trac tickets to specifically disallow unrelated or partially related changes to be made. This may be somewhat hard to determine, but when in doubt, better to create a new ticket instead of exponentially extending an existing ticket. In 5.3 there are several examples of such “run-away” tickets: #47477, #47153, #34904, etc.


* The slower commit pace during alpha is partially due to new features being developed, and not committed until deemed “ready”. Another reason is perhaps that complex enhancements 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 need more research, reviews and testing before committing. Yet another reason is that perhaps most contributors focus more on the new features, enhancements and more complex bug fixes leaving the “easy” bugs for later.

Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1578447001","hasChildren":false,"userLogin":"TimothyBlynJacobs","userNicename":"timothyblynjacobs"},{"type":"comment","id":"37752","postID":"78985","postTitleRaw":"5.3 Release Cycle Post-mortem","cssClasses":"comment byuser comment-author-azaozz bypostauthor even depth-2","parentID":"37751","contentRaw":"

...media retries dev felt very fast and barely made the RC deadline. For me at least it was fairly stressful.<\/blockquote>\n\nYeah, it turned out to be quite more complex than expected, was very stressful for me too. The good part is we managed to do it in time :)\n\n
Moving forward, could the focus be announced at the beginning of the cycle or perhaps even while the previous cycle is closing RC?<\/blockquote>\n\nYes, this would be great, perhaps not always possible. Sometimes the ideas\/need for new features and enhancements come in later, even during the kick-off.\n\nBugfixes are (mostly) unaffected by the release focus(es). Each team\/component maintainers can prioritize which bugs should be dealt with next, which would require cross-component consideration\/reviews, and which are more likely to introduce problems\/regressions and should get in \"early\" to allow for better testing.","contentFiltered":"

\u2026media retries dev felt very fast and barely made the RCrelease candidate<\/span> 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 Untrash<\/a><\/li><\/ul><\/nav>","mentions":[],"mentionContext":"","commentCreated":"1578448113","hasChildren":false,"userLogin":"azaozz","userNicename":"azaozz"},{"type":"comment","id":"37753","postID":"78985","postTitleRaw":"5.3 Release Cycle Post-mortem","cssClasses":"comment byuser comment-author-mte90 odd alt thread-even depth-1","parentID":"0","contentRaw":"Just a comment, maybe the alpha period need to be more long as period to give to the various teams time also with few resources to follow everything?\n\nI think that there was also the problem of the new theme in the 5.3 with few tickets about bugs, and a new theme is unusual for a wordpress release.","contentFiltered":"

Just a comment, maybe the alpha period need to be more long as period to give to the various teams time also with few resources to follow everything?<\/p>\n

I think that there was also the problem of the new theme in the 5.3 with few tickets about bugs, and a new theme is unusual for a wordpress release.<\/p>\n","permalink":"https:\/\/make.wordpress.org\/core\/2020\/01\/08\/5-3-release-cycle-post-mortem\/#comment-37753","unixtime":1578472577,"loginRedirectURL":"https:\/\/login.wordpress.org\/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2020%2F01%2F08%2F5-3-release-cycle-post-mortem%2F%23comment-37753&locale=en_US","approved":true,"isTrashed":false,"prevDeleted":"","editURL":null,"depth":1,"commentDropdownActions":"","commentFooterActions":"","commentTrashedActions":"