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

Aaron Jorbin 7:32 pm on December 8, 2016
Tags: , retrospective   

4.7 Retrospective

A retrospective meeting on the WordPress 4.7  release will be held during the week of December 19th. In order to properly prepare for that retrospective and make the time as productive as possible, I would like to encourage everyone to comment below with things they would like to bring up. To help, here are three good 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 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.

#4-7, #retrospective

Konstantin Obenland 3:15 pm on September 23, 2015
Tags: , , retrospective   

4.3 Retrospective Results

I missed posting the 4.3 post mortem recap before I went on vacation, so without further ado:

We discussed the 4.3 release 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/., where I asked for things that should be improved and things that went well, in order to get some feedback on how I did and helpful tips for future release leads (please find the Slack log here):

Should be improved:

  • Figure out some ways to get more testing and more eyes on betas and RCs.
  • Not having feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. complete (with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.) before the merge window.
  • The menu customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. proposal could have been written differently in anticipation of community perception.
  • The people who are able to test term splitting properly are very limited. Not sure how to wrangle people for this kind of specialized testing.
  • there seemed to be a lack of movement at the end of the cycle.
  • Features like site icon should be done as a feature plugin.
  • The merge proposal could have been proof-read by someone from the core team.
  • Getting dev-notes written up earlier.
  • There were also not a lot of feature plugins ready for core at the start of 4.3.
  • Don’t think it’s really okay to be relaxing standards in the name of forcing something to fit a deadline.
  • We did a freeze/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). maaaaybe 24 hours before release that had significant changes in it, that did not feel good.
  • We completely changed features after 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.
  • I think in 4.2 we discovered that have a core mentor involved much earlier also helped get it to that “ready” place. Or closer to ready.
  • Find a way to increase participation for 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.

Went well:

  • passwords went really well.
  • We had a solid crop of guest committers that really made things go well for there project area.
  • Update to 4.3 went really smoothly over all as well.
  • We had some epic traction on Formatting component patches during this cycle. I’m a bit surprised how many tickets we closed with 4.3 because those are usually very problematic.
  • Touch and small screen usability improved significantly. Two of my top five issues were fixed outright and progress was made on a third.
  • I demoed the keyboard shortcuts in the editor to some people and they were like “DAMN, that’s amazing”.
  • i’m really happy about list table changes!
  • Shared taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. terms are dead.
  • WE RELEASED ON TIME!!!!

I’m probably a little biased, but contrary to what the amount of bullet points in each section might suggest, I agree with @samuelsidler who said: “Almost everything went really smooth.” I’m proud of what we accomplished, and the download and update numbers speak for themselves. Thank you again for everyone who helped out during the release, let’s make 4.4 even better!

#4-3, #post-mortem #retrospective