 Welcome to the WordPress Briefing, a 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 Hayden-Champosi. 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 and by the numbers, it looks really good. 66 enhancements or feature requests went in, 127 bugs were fixed, and seven whole versions of the 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. And there's not really a reason to know unless you're actively contributing to a release. But for those who are interested to know more about how we improve WordPress, this week's exploration is for you. We're going to take a look at what goes into WordPress releases and just kind of zoom our way in from the highest level. So starting at the highest level, working our way in, highest level is there are about three major WordPress releases a year on average, plus the minor releases, plus, 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 and maybe more. 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 pulling together 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 have been kind of simultaneously. The first part is planning and includes the project lead devs, design, things like that, groups like that rather. 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 team, core and editor, mobile, various other teams as well. And then there's this phase that I like to refer to as the distribution phase. It is mostly the teams that make sure that WordPress is widely distributable. So the polyglots team work on translations. Accessibility does some work. Docs makes sure that everything is documented and then training of course gets things ready for when we have to be able to tell people how to use the release. And then there is a fourth ish phase. I really don't think they go sequentially. I don't think they're really in kind of a waterfall format. But the fourth ish phase that I include in 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 kind of show up and help us to make sure that WordPress is available not only widely, but broadly to make sure that their audiences as theme authors and plugin authors, etc., etc., are covered in the features that they need based on what they are using WordPress for. And then this fifth ish phase is our communications part. That involves the community team especially, but also marketing, WordPress TV, learn.wordpress.org, basically anyone who's showing up to make sure that we all are sharing 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. And then if we zoom in a bit more on the creation phase, each release has people who lead the work and kind of coordinate contributor efforts during the course of the release. For any given release, there are hundreds of people who contribute and receive credit for helping move the WordPress project forward. Okay, hold on a second, let's let's pump the brakes and zoom in a bit on that. Hundreds of people doing 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 a release, it's actually pretty substantial. For every release, there is a small team of leaders who ask the hard questions. Is this a usable feature? Does this make WordPress better overall? And of course, is this ready to ship? And some of those leaders, so a smaller subset of even the leaders that we have in there 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. But 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. All right, 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. First is that the code is readily available. If you have a basic understanding of the languages, then you can see the code, learn from it and make suggestions about how to improve it. Second is that you consider your users, co developers in the process, which means that as long as your product is used by people, those people will have opinions on what you shipped. This way of iterating, this way of improving WordPress ties back to one of my favorite open source principles, the idea that with many eyes, all bugs are shallow. Because to me, that means that with enough people looking at a problem, someone is bound to be able to see the solution. Which brings us now 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 Nook in our Bangkok community. When asked who helped her find her way in the WordPress community, she said, Shinishi Nishikawa, who started the WordPress community in Bangkok and encouraged me to contribute. And also, Myo Moriyama, who introduced me to the WordPress community team and encouraged me to join as a deputy. Thank you for sharing those two inspiring people with us, Nook. 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, 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 take a listen to the artist that it's named after. The second thing that I want you to keep an eye out for is on WordPress.org slash news. We are starting a new series of content that gets at the heart of some of the basic parts of Gutenberg. 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 it is that we're trying to change and where those changes are primarily taking place. So there will be a couple of tutorials that go up there over the course of the next few weeks. And I would keep an eye out and share when you see it. And especially if you find it useful, let us know. The third item on the smallest 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 co-developers. The software that is being built is supposed to be making your life and your work easier. And so when you test things and you 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 so that we can 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 slash 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 smallest of big things. Thank you for tuning in today for the WordPress briefing. I'm your host, Josepha Hayden-Champosie, and I'll see you again in a couple of weeks.