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

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.

#6-0, #retrospective

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.

#5-9, #retrospective

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!

#5-8, #retrospective
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.

#5-4, #retrospective

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.

#5-3, #retrospective

Francesca Marano 8:09 pm on November 15, 2019
Tags: , retrospective   

5.3 Retrospective – Call for feedback

5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!

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 share your thoughts in the comments below! 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.

Edited to Add: if you rather not give your feedback in a public space, please reach out to the following people on 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/.. They are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form:

#5-3, #retrospective

Josepha 9:02 pm on May 10, 2019
Tags: , retrospective   

5.2 Retrospective

As we finish up one release and start looking forward to the next, I’d like to take the time to let people share their thoughts on how the 5.2 release process went. I have listed three questions I’d like feedback on below.

  • 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 share your thoughts in the comments below! 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.

#5-2, #retrospective