 So let's spend a few minutes talking about how WordPress is made. Who here has followed a WordPress release before? Okay, cool. So some of this is going to be reviewed for y'all, but We're going to do it anyway. So I'm sure you're here at a lot here at WordCamp, but you can find references for everything that I'll chat about and information about the various WordPress contributor groups at make.wordpress.org. So that's a really good reference point. I'll be talking about that a lot. The most important thing to mention starting out is that making WordPress is a team effort. So that's why we talk so much about contributions and the community. Most of those who work on WordPress are not paid to do so, but are volunteers with only a few that have time that's donated from their employers to further WordPress. So for instance, my employer Dreamhost donates about half of my time to work on the project. That is, it's really only a few of us, and it is not the general case. This is the top of the credit screen for WordPress 4.6 and you'll notice that the the project leaders are there and underneath are contributing developers, which include both committers who can who have access to add code to WordPress, but and also folks that have put in a lot of time on specific features get featured with photos here. But really the part that's most interesting to me is this last section. So after the photos, there's this list, and this is every single person that contributed to WordPress 4.6. So this is 272 contributors for WordPress 4.6 and this number gradually goes up over time. So it really does take the entire community to make WordPress and every single person that contributes even, you know, a small bug fix or a test or or whatever it or whatever it is, is really important for making WordPress better. So that's a lot of people. Where does that communication happen? So I've already mentioned make.wordpress.org. So the main channels are make, slack, and track. So make has running information about the different meetings that that go on synopses. Dev notes get posted near to the end. So because we're near the end of the 4.7 release cycle, you can go there and see a lot of information about what's changing in WordPress 4.7. Slack is used for real-time meetings and also both real-time and real-time and one-to-one communication. So that if you're working with people across time zones, which happens quite frequently, it's it's easy to do that and you can sign up for Slack on make.wordpress.org if you want to participate or even just kind of see what's going on there. Finally, we use track as our issue tracker. So for bugs and for features to see what's going on with them and to keep track of all of the things that that are being worked on. That is also where all of the discussion happens regarding code that that folks have posted to for potential inclusion into WordPress. So discussion happens there with patches, you know things that are things that are that need to be changed or even just to iterate on an idea to make sure that we have the best solution before it goes into core. All of that conversation happens on slack or on track. So the WordPress release process is always kind of is always kind of changing based on based on what's best for the project at the time. So consider this to be information information sort of for now with that we're constantly kind of kind of going through making that better. But at the moment it looks like this. So planning and future projects are something that are ongoing kind of all the time and Then we follow through alpha beta RC and release and RC is a sensible release candidate I'll go through exactly what each of those things are. So it's almost a loop but not quite. Ongoing is is planning or at least that's that's the idea. I think I think this is a stage this is a part of of WordPress development that could probably work a lot better than it does currently the idea is that The idea is that planning for future releases by the chosen release leads happen sort of ahead of time. So if they're So last year at WordCamp US there were three release leads that were announced. So the idea would be that each of those Release leads that are happening later in the year that are happening or that have a release that's later can go through planning with their team select a team Start start thinking out what vision they're going to have putting together some projects so that they have that sort of that time for development between Knowing and and the release actually happening. And I think this is a this is a way in which we've kind of fallen short really in the WordPress project recently. And and there are some ways that that we can fix that. So during the planning the so the release leads are chosen from a sort of volunteer process and then discussed by the core leadership team and for the decisions as to as to who they actually are. And the release lead has the final say over what ends up going into a release. They also choose their team of deputies to work with them to help to help build that release. And the focus of the release. So for instance for WordPress 4.7. There's a lot of emphasis on the initial user experience and getting a site set up for the first time. The first stage once once development hits is alpha and the idea with alpha is new things. So this could be new features or it could be enhancements enhancements are generally something making something existing work better or to improve a user flow. Whereas features considered to be something entirely new like the custom CSS that's coming in WordPress 4.7 or broken link checking back with 4.6 looked around a bit is sometimes the distinction between enhancements and features is a little bit fuzzy. And I found this one from a couple of releases ago. I really like this. So this link search for plugins in the WordPress plugin directory was something that was added after the fact. So it wasn't there. It wasn't there before the release and it got added. So the previous behavior was that you would search for a plugin in the plugin screen and you would see no plugins found for WP Supercash wherein it's I don't know. To me at least it's pretty clear that probably what the user would want to do is install that plugin if they don't have it. So instead something was added to click on that and you can click and directly go over to add plugins and install the plugin and you've and you've got it all set. Eventually I would love to see this as something that is even more integrated into that screen where you don't have to click over to another to another page and you can just install the plug in there. But I think this is a really great example of a sort of gradual enhancement of WordPress. So feature projects are are something that are also going on constantly between releases. The idea behind this is that features shouldn't need to be bound to a particular release cycle and instead their development should be able to continue for several and then there's a window at the beginning of each release for that feature being merged. And sort of the decision as to whether it's ready or whether it should wait. This is feature plugins or projects are a thing that sort of came out of necessity after the move to shorter release cycles. So because our release cycles are only are only a few months it it doesn't leave very much time for development of new features between each one. And so the idea behind this is to is to sort of solve that problem. I think that it's something that we haven't quite figured out figured out quite yet. So I really like I like the idea. But in practice I think there hasn't. There there the result has been that there haven't been very many projects that are introduced each cycle and in part due to really due to really process and and having having it be easy for folks to introduce them. And having there be vision to inform what they should be. And after that I think there's been a little bit not maybe not quite enough communication with those projects and and the core and the core team to be able to to be able to sort of help them move along the along the right direction. And so I I'm not sure exactly what the what the solution is. I think communication is probably the highest one. But I like this idea. And I think that at the very least it has it has allowed for more consistent release cycles. You can see on make dot wordpress dot org a list of all of the the current feature plugins or projects the ones that have already been merged. And you can see here each one is required to have a weekly chat. That's a little bit of of process that I that I really like. And so you can go there and you can chat with the team each week and you can get involved. There's also a list here of all of the documentation so that you can get directly linked to it. The next set or the next stage is beta. And the idea here is to make the software stable so so add new things. And of course you during during alpha you can also fix bugs. But as soon as you hit beta it no more enhancements or features are allowed. Usually they're about four betas in the release cycle with a release schedule these week each week. So things that you can do during beta would be to help test the release report problems and help with those fixes. After that we hit the release candidate. At this point it should be almost done. It should be really what what we expect the release to actually be. Oftentimes there's some stuff still left over. But notably notably often the about page is something that that gets to that that's done near the end. But usually we get pretty close on this and there aren't that many changes during the release candidate. There are restricted rules on those commits so only fixes that are either severe for new features or would block a release are allowed in and there's double authorization from core developers or lead developers for any code that is going to land in core. At this point releases happen whenever are really necessary for those commits. Since in theory they should be few and far between. So during this stage you can test the release test your plugins test your themes and test your client sites with an expectation that this is going to be what the next release is going to look like. So at that point we release. Yeah I don't know I couldn't I couldn't do a presentation with dash in the title without rainbow dash so you know and very shortly after we go again so Dominic gave me a little bit of break meaning until the next week's dev chat between four five and four six starting but it's become increasingly common for the talking court to immediately in slack go to talking about the next release and I don't think that's necessarily bad. Dominic and I know did a lot of planning ahead of time with you know connecting with people finding out what they were available to do and scheduling and what they were interested in working on and all that stuff happened sort of you know simultaneously as as is by design. And so I think that one of the things that WordPress is doing well at the moment is that we have we have three major releases a year one every four months and I think that the the team the community on a whole has gotten pretty pretty good at sort of maintaining this and having it be a stable process. So right now what that looks like is that alpha is about two months and beta and RC combined or two months so about half for new things and half for stability essentially. So this is this this does work but it I included this to kind of point out that really two months is very very very little time for development of new features and so that's what requires. That's why sort of feature projects are required but it also means that if that process fails then there's probably not going to be very much for for that release. That is that is new features essentially so you may wonder why they're tight deadlines here and that's because one of the WordPress core philosophies is that deadlines are not arbitrary. As a quote from there from that page and I suggest you check it out if you haven't read through it before because it gives a lot of insight into the project deadlines are not arbitrary their promise we make to ourselves and our users. They almost always make you trim something from a release it's not a bad thing it's what they're supposed to do and that helps you avoid from falling into that rabbit hole of always one more feature. You can see all of the current development cycle on make that WordPress dot org and all of the different dates. So to recap alpha new things beta make it stable RC almost done. If you want to help out we are in the release candidate for four seven right now so you can always be testing. You can download it directly from WordPress dot org at the release candidate is there and or you can use the WordPress beta tester plugin to test the current version of the code. I am Mike Schroeder I'm a core developer and director of WordPress strategy at dream host you can find me on Twitter at get source and it gets source dot net thanks.