How WordPress Improves

In this episode, Josepha Haden Chomphosy explores the WordPress release process. Tune in and learn the phases of a release and catch this week’s small list of big things.

Have a question you’d like answered? You can submit them to wpbriefing@wordpress.org, either written or as a voice recording.

Credits

• Editor: Dustin Hartzler
• Logo: Beatriz Fialho
• Production: Chloé Bringmann
• Song: Fearless First by Kevin MacLeod

References

• WordPress 5.7 “Esperanza” 
• Esperanza Spalding
• Gutenberg Tutorial: Reusable Blocks
• make.wordpres.org/test
• GitHub repository 

Transcript

Hello, everyone, and welcome to the WordPress briefing, the podcast where you can catch quick explanations of some of the ideas behind the WordPress open source project and the community around it, as well as get a small list of big things coming up in the next two weeks. I’m your host, Josepha Haden Chomphosy. Here we go!

All right, so last week, we wrapped up and shipped the WordPress 5.7 release. The release team this time around was smaller than we’ve had in the last couple of years. By the numbers, it looks really good: 66 enhancements or feature requests went in, 127 bugs were fixed, and seven versions of a Gutenberg plugin were merged and backported. If you use WordPress, you are probably aware that we have new releases throughout the year, but you probably don’t know much about the release process. There’s not really a reason to know unless you’re actively contributing to a release. For those interested in knowing more about how we improve WordPress, this week’s exploration is for you.

We’re gonna take a look at what goes into WordPress releases and just kind of zoom our way in from the highest level. At the highest level, there are three major WordPress releases a year, plus the minor releases, plus Gutenberg releases. So if you’re following current WordPress work and future WordPress work, that’s going to get you to probably around 30 releases a year. If we zoom in one level to the release itself, a single release of WordPress takes four to five months from start to the day that we ship, and an additional four to six weeks on support and translations, and minor releases after that. If you’re looking from my vantage point, you’ll see that WordPress releases have essentially five parts, some of which happen kind of simultaneously. 

The first part is planning and includes the project lead, lead developers, design; groups like that. The second phase is the creation phase when we’re actually building the things that have to go into the CMS that involves the design, core, editor, mobile, and other teams. Then there’s this phase that I like to refer to as the distribution phase. This is mostly done by the teams that make sure that WordPress is widely distributable; the polyglots team work on translations, accessibility does some work, docs make sure that everything is documented, and training, of course, gets things ready for when we have to be able to tell people how to use the release. 

Then there is the fourth phase; I really don’t think they go sequentially or in a waterfall format. The fourth-ish phase that I include, and that I tend to see, is this extending and iteration phase. It’s the phase where we see our theme authors and our plugin authors, folks who are doing support, show up and help us to make sure that WordPress is available not only widely but broadly to ensure that their audiences as theme authors and plugin authors are covered in the features that they need based on what they are using WordPress for. The fifth phase is the part of our communication that involves the community team, especially marketing, WordPressTV, and learn.wordpress.org. Basically, anyone who’s showing up to make sure that we all share what happened in the release, the features that are coming, and how that affects the users is involved in that particular phase. So five big phases of what happens over those four to five months, and then for the month or month and a half afterward. 

If we zoom in a bit more on the creation phase, each release has people who lead the work and coordinate contributor efforts during the course of the release. For any given release, hundreds of people contribute and receive credit for moving the WordPress project forward. Okay, hold on a second. Let’s pump the brakes and zoom in a bit on that. Hundreds of people work on every major release for a project that powers over 40% of the web that feels like a small number. But for the people who process the contributions in preparation for release, it’s actually pretty substantial. For every release, there is a small team of leaders who asked the hard questions. Is this a usable feature? Does this make WordPress better overall? And, of course, is this ready to ship?  Some of those leaders, a smaller subset of even the leaders that we have already, are committers who actually prep and merge patches to the CMS; they don’t do all the work to create a design or write all the code. This tiny group of people processes hundreds and hundreds of bug fixes, improvements, and enhancements that have been submitted over the course of months and sometimes years. As a side note, that whole process is a little smaller, a little faster in the Gutenberg featured plugin, but the basic parts are still there. Alright, so we’ve zoomed from the big picture way into some of the finer details, and it really looks like any other project cycle. So now, I’m going to layer in the filter of open source to that process.

There are a couple of things that make building software in an open source environment so different. The first is that the code is readily available. If you have a basic understanding of the languages, you can see the code, learn from it, and make suggestions about improving it. Second, you consider the user a co-developer in the process, which means that as long as people use your product, they will have opinions on what you shipped. This way of iterating improves WordPress and ties back to one of my favorite open source principles. The idea that with many eyes, all bugs are shallow. To me, that means that with enough people looking at a problem, someone is bound to be able to see the solution.

This brings us to our community highlight, the segment where I share a note about contributors who have helped others along the way or a WordPress success story. This week’s highlight is from Nok in our Bangkok community. When asked to help her find her way into the WordPress community, she said, “@shinichiN who started the WordPress community in Bangkok and encouraged me to contribute, and also @mayukojpn has introduced me to the WP community team to join as a deputy. “ Thank you for sharing those two inspiring people with us. And if you, listener, have any stories that you would like to share of your own WordPress success or people that you have been so grateful to help you find your way in the project, you can feel free to email those to me at wpbriefing@wordpress.org.

That brings us to our final segment of the WP Briefing, the small list of big things. I only have three things to share with you this week. The first one is that about a week ago, we had our first release of 2021. It was the WordPress 5.7 release, titled Esperanza. If you have not yet seen it, go ahead and update your website or check with your host and make sure that they have updated you if you’re on a managed host. And then take a listen to the artists that it’s named after. 

The second thing that I want you to keep an eye out for is wordpress.org/news. We are starting a new series of content that gets at the heart of some of Gutenberg’s basic parts; there’s a lot of change coming up in the next few releases of WordPress. And the most important thing to me is that you understand what we’re trying to change and where those changes are primarily taking place. There will be a couple of tutorials that go up there over the course of the of the next few weeks. The third item on the small list of big things is to remind you of our call for testing. As I mentioned earlier in the podcast, the users of any open source software are the code developers; the software built is supposed to make your life and work easier. When you test things and find interactions that can use a little bit of refinement or features that are not working exactly as expected, it’s incredibly helpful for us to have that information to always make sure that we’re solving problems instead of accidentally creating them. If you want to participate in the Current call for testing, you can head over to make.wordpress.org/test. Or, if you’ve been doing your own testing, you can also submit any bugs you have found in the GitHub repo, which I will share in the show notes below. So that, my friends, is your small list of big things. Thank you for tuning in today for the WordPress briefing. I’m your host, Josepha Haden Chomphosy. I’ll see you again in a couple of weeks!