WordPress 4.9.5 was released a couple of weeks ago, at the scheduled time and without known issues.

We (@audrasjb and @danieltj) had the pleasure to co-lead this minor release of the CMS, with @sergey‘s invaluable help as deputy and @jbpaul17’s mentorship. For this release, we were two co-leaders, contributing to the core for a short time, and none of us had core committer status. Thank you all again for trusting us for this task.

Below you will find some feedback and tips we wanted to share with you and we hope this will encourage others to get involved in such an adventure.

To lead a WordPress release, you don’t have to be a core committer,
you have to deeply care about the WordPress open-source project.

Initially, we wondered how the two of us could claim to run a WordPress release without commit access.

In fact, there are many tasks that are not related to the commit action itself, but require a good knowledge of the ecosystem, the people and teams involved and how the release process works. Here are some examples of tasks to do:

• Triage: sorting tickets and status update. This is a very time consuming task, because you have to dive into each ticket, read all the discussions and check if the patches are ready to land in your minor version or not.
• Bug scrub meetings: these take place in the #core Slack channel and is about sorting Trac tickets to check if the patches and improvements are on track. You have to ask the Component Maintainers, designers, accessibility specialists or focus leads to help their resolution. We must plan a bug scrub a week or two prior to the release.
• Dev chats: the weekly meetings of the Core team to discuss progress of the current release, to talk about future releases and to focus on particular points. I had a hard time on that side for the first dev chat I led with the launch of a lively discussion around Gutenberg’s merge proposal and WordPress versioning. In this kind of situation, you have to stick to a rational approach and try to allow everyone to express themselves.
• Post writing, Trac tickets answering, codex editing and all stuff related to communication. This is very time consuming, so prepare it carefully.

You must also organize yourself for the release process. The complete process is detailed in this handbook: Releasing minor version.

Key moments of a WordPress release

• D-30 to D-15 – here you are, leading the next minor version of WordPress:
  
• You should go around all tickets tagged for this minor version. Take time to read each ticket carefully. During your bug scrubs, you’ll have to be comfortable with each of them, especially with their progress and last discussions. Feel free to get in touch with the related Component Maintainers.
• Feel free to check out other tickets tagged for the next major release and are already committed. It is quite possible to bring them back to your minor if they are self-contained fixes (and not enhancements) and do not result in any new file being created in WordPress core. We were able to repatriate 5 or 6 patches WP 4.9.5. Personally, I managed a spreadsheet with all the tickets to watch. This document helped me a lot later.
• Prepare each bug scrub and dev chat in advance: it’s better to copy and paste at these meetings so you can follow the discussions as well.
• Ask for access to write posts on Make/Core and to be able to notify contributors in the core Slack channel with @here command.
• D-15 – Beta release:
• Last bug scrub: all tickets must be committed in the branch. Those who are not ready must be “punted” to the next release. Do not take any risks.
• One day before, contact lead developers to make sure someone will be available to build your RC package. Do not make the same mistake we made: we ended up with a ready beta but no one to build the package. You must warn Mission Control people in advance!
• Publish your post on Make/Core : reuse previous posts format and indicate changes so people can test your beta.
• D-7 – Release candidate:
• Final Bugscrub: Some last tickets may be committed for RC, but they must have been checked by an experienced core-committer and approved. Besides, two checks are better than one.
• One day before, contact Mission Control to make sure someone will be available to build your RC package.
• Publish your post on Make/Core.
• Bump version number and update changelog for all concerned bundled themes. Here is the standard Trac ticket I made.
• D-2:
• Get in touch with the Akismet team to check if a new version is ready to land in the release.
• Get in touch with the people in charge of bundle themes and ask them to prepare to deliver a new release of the related themes on w.org.
• Get in touch with Mission Control team and ask them for their availability for the D-day.
• D-1:
• Get in touch with the Security team (usually they will come to you) to know if security patches will land in your release (we had three security patches). Obviously, this information is confidential, you can not communicate it.
• Prepare the changelog of the new version with the complete list of changes for the Codex changelog (if the release contains security patches applied to all the supported branches, it would be necessary to make a new page for each version!) And for the Make/Core post.
• D-Day:
• Build the packages (current branch + previous branches if a security patch is delivered) with Mission Control team.
• Ask Meta team to prepare the list of contributors of the release and to update credits API.
• Prepare to publish the Make/Core Post and the /News Post, they must be published right after auto updates start.
• Prepare some standard announcement such as “@committers please refrain from committing while we package the 4.9.5 release.” or “Heads up to everyone following along: We’re in the process of releasing right now. You’ll see some builds appear in this channel, but we have not released until there is a new post on WordPress.org/news/. Please do not tweet, publish, or otherwise announce a release until there is a public post about it on WordPress.org” for Slack, to repeat regularly during the build process.
• Prepare local test instances to test each package of each version of WordPress on different PHP environments. Hopefully, other contributors can help you test the packages on their side.

Once launched, that’s the big day. The release is built and auto updates will be done on WordPress installations around the world. Feel free to ask the Mission Control for some statistics – the figures are incredible. Unfortunately, it is not publicly available, but you will certainly be pleased to know in real time the number of people who are enjoying your work.

At the next devchat, you will carefully follow the feedback from the Support Forums team who will give you feedback from users. Fortunately, in our case, nothing went wrong.

Various remarks

• Remember to warn the people who have Mission Control access a day or two before each release (beta, RC, final release). Without them, you can’t do anything! In our case, we did not manage the beta and the RC very well and only succeeded at the last moment. Thank you for those that helped, who were understanding and caring.
• An issue when you are relatively new in Core development is to find the right people to contact. Do not hesitate to get in touch with as many people as possible, they will put you touch with the people who can help you. Remember: you can’t build a WordPress release alone.
• Do not hesitate to get in touch directly with the people who can help you: Component Maintainers, Focus Leads, Theme and / or Plugin Teams, Mission Control, Security. A little introductory message at the very beginning of the release does not hurt, and everyone will be very happy to help you if needed.
• Attend as many component/focus meetings as possible. Some changes may affect your release and it allows you to know how specific tickets are doing.
• Plan about three evenings a week to work on the release, during a month. It depends on your timezone but in my case, I had to book at least every Tuesday and Wednesday evening, sometimes until very late at night. Outside, you will also follow what happens in the tickets throughout the week. Tell your boss to get some time for it (thanks to my agency for giving me some time during office hours).
• Organize well so you do not have any last minute surprises. For example, we were ready to integrate the “Try Gutenberg Callout” or not, and we considered both solutions, whether on the general organization or during changelogs writing and blog posts on Make/Core.
• If you are running as a co-lead (which is better), alternate the lead equally so that everyone can enjoy the experience of triage, bugscrubs, developers chats and the whole release process.
• [more personally] If you are not a native English speaker, it’s not the end of the world: focus on putting your ideas first. Nobody will reproach you for not speaking perfect English. WordPress contributors are kind, understanding and professional people.
• Enjoy all this because time flies!

In conclusion, leading an open source project is above all, rewarding and difficult. It’s no easy feat to manage a team of volunteer contributors and ensuring things run smoothly is a challenge in and of itself, let alone the bugs! Constant communication and asking questions will always put you ahead. No one should feel ashamed to ask an easy question and those kinds of questions are very welcome. Sharing knowledge is more powerful than feeling bad that you don’t know the answer. You should also feel like you can lead too. This doesn’t mean telling people what to do, but being firm and leading and making decisions makes everything move forward much more quickly. To sum up, the human part is just as critical as the technical part of the project.