 So, I'm sorry to disappoint all of you who are waiting for Scott. I'm unfortunately not Scott Taylor, and I don't work at the New York Times, and I don't know enough about translation and internationalization. But I am learning, and, but I basically wanted to give anyone the opportunity who actually thought it was going to be Scott. If you want to go out, I will not be upset. But, if you want to learn about decision making in WordPress Core, then please stay, and we'll hang out for a while. So, what I'm going to do is talk through a few of the different philosophies behind decisions in WordPress, and along with that, give a few examples of the real world of just the last couple releases of how those decision making processes have played out. Along the way, hopefully, you'll both learn a little bit about how to contribute to those decisions yourself, or, at the very least, how to follow them and see the decisions as they happen. This is, of course, I've got to talk more about how it is than how it should be. I definitely think that there is lots of room to improve the things that we do in core and the way that decisions are made, and so what you're going to be seeing is a bit of the real world. So, let's move on. If you remember one thing from this talk, it is make.wordpress.org. So, what I would like to do is, every time we get to a place where I redirect you all to WordPress.org, or to make.wordpress.org, let's all say make.wordpress.org, okay? Can we do it? One, two, make.wordpress.org, okay? I'm sure we'll get used to it by the end. So, let's move on a little bit. In reality, the way that decisions work in WordPress is some procedure, but it's mostly principle. We've been slowly adding procedure over time, especially to certain aspects of the project, but it's still mostly on principle. We have decisions that are guided by consensus with the team and the various teams that work on WordPress core and guided by philosophy. And you can see right there a link to check it out. I'm not going to step through all of the points in the philosophy page because we don't have quite enough time for that. But if you're interested in the philosophies that guide WordPress and you haven't taken a look at that before, I would look through it because I think that it'll shine a lot of light on the decisions that have been made and that are being made for you. So, before we get to some examples, let's go over a little bit of background information. There is a structure to WordPress, and on this rather messily laid out slide, you can see generally how it works. You have Matt, who is the project lead, five lead developers, followed by the permanent committers, guest committers who are really more trial committers, and followed by the component maintainers, and of course, all of the contributors. This also doesn't include the release lead, who has the final say over what goes in any particularly release. In reality, this is less of a direct decision tree and more of an escalation tree to be used only when necessary. Those who are working directly on the code make most of the decisions about that code, and it only needs to be brought up when it needs to be. So, usually, these decisions instead are made according to these philosophies, with preference to those who know the topic the best. Usually, this turns out to be the contributors who are either directly writing the code for features or patches, and the component maintainers. So, we'll loop back to this in a little bit. One thing that the WordPress project has been working on a lot is trying to nail down exactly how to build features and ship them with core. Several years ago, it was often the case that someone or one or two people would spend a ton of time during a release, and all of the features that were shipped in it were all built from the beginning of the release to the end of the release. We're trying to change this a little bit, and so in the past couple years, there's become a thing called plugins as features. So, the idea is that you can build a feature for WordPress over several releases, and it's easily testable by a lot of people, because you can just install it as a plugin, and you can get going. This has been slightly modified recently to be called feature projects with the idea that the focus is on the goal, on the product goal for WordPress, and the feature that we're looking for rather than on it necessarily needing to be a product, and focusing more on that planning ahead of time so that you don't hit the end and end up having to cut things or have it look like, oh, well, that's not quite what I thought it was going to be. That doesn't quite fit, so plan more ahead of time rather than doing so closer to the end. This is one of the few areas of core that has significant procedure regarding the requirements for the features landing in core. So this decision to feature projects and feature plugins was largely because another one of the core philosophies is that deadlines are not arbitrary. So what this allows us to do is instead of being in situations where having a certain feature make it into the release, delays a release, and then delays it again when you think, oh, no, we're almost there. Instead, we can just say, let's build this. We're building this particular thing. And when it's ready, at the beginning of a release, we can evaluate it and see if it's appropriate to go into WordPress. So the way that this works is that there is a window at the beginning of every release, or usually a few weeks in, that is a week long, and the decision is generally made if it's going to be targeted right at the beginning, and then it needs to be merged or added to the WordPress code during that week. So I'm going to give an example from WordPress 4.6 about how this happened. So Shiny Updates is a feature that is being built to make it. So there was a Shiny Updates version one that went in a few releases ago that allowed you to update your plugins directly in the plugins screen within WordPress, where you just clicked it, and it would kind of spin for a bit, and then it would be installed as opposed to having to leave it. So this is the second iteration of that. It adds things like installing plugins and themes directly from the area without leaving somewhere else. You no longer have that. They like to call it the bleak screen of death that you click on install, and then you see lines of text come down, and it's not always clear, especially to users who are not very technical, what that means or what to do about it. And it also adds another step in the process. This is a big thing, because one of the WordPress philosophies is to design for the majority. And what this means is to target those who are non-technically minded and make sure that they don't need to worry about those interruptions that the technology might add. The other specific focus that this feature was going for is the philosophy of striving for simplicity. So initially, I was reading through this philosophy page and one-click Upgrades. So the initial back when all the time you had to install the upgrades manually, it was a bit of a pain to upgrade WordPress. And they added the feature so that you can just click a button or now even set it to do it automatically, and you just upgrade WordPress, and it's done and you don't have to worry about it. And so I see this feature project as very similar to that, essentially. It's adding one less step that a user has to worry about, and they can just continue managing their site and keep going. So this feature project was started around the beginning or right before the beginning of WordPress 4.5. And so they worked on it throughout the release, and we came to the moment where they had to decide. And Constantine decided that there would be no shiny updates for 4.5, to which I was a little sad. But the reasoning is that it's important for features to be polished before they land in core. And following the feature project, feature plugin route, it was absolutely the correct thing to do. So they made that decision. Again, deadlines are not arbitrary. We hit the deadline for the decision. It wasn't ready. So we moved on. This came up again as soon as we hit WordPress 4.5. So we had to make the decision, is this ready to go into core, or is this not ready to go into core? So at the meeting at the very beginning of that, we talked about this. There's a page that is on make.wordpress.org slash core. And it's inside the handbook that has all of the different criteria that you have to hit for it to be allowed to go into core. And so we were going through all of the checklist. Dominic, the release lead, was leading us through it. And we hit a concern. We realized that it had been requested to have a final design review, but it only happens sporadically with comments given in separate places and with separate issues on GitHub, but not a global design review from the design team. So the decision was made to set a deadline for that feedback to happen and then to make a decision at that time based on the design team's feedback and giving them the ability to veto what we were going to do. And so it went ahead and it happened. We set up that meeting to go ahead. And the first reviews started coming in from the design team. It turned out that there was a particular section of the shiny updates, of the shiny updates feature plugin that wasn't quite ready, but it looked like the rest was. So the release lead, the design team, the lead developers, and those who worked on the plugin all together to come up with a solution for it and the way to move forward. It was eventually decided by the lead of the plugin, by Constantine, that it made sense to put that part aside and continue with iterating on it for the next to potentially have it landed in another version of WordPress. And I fully expect that it will. And to just put into WordPress what was ready and not ready by the design team, giving them the authority to do so. After that, Dominic double approved it, release lead, and the decision was made to merge that, and it was merged about nine days ago. I actually really enjoyed seeing this process go on because the voices of all of the different levels were heard and respected. And I think we ended up with a solution that's a lot better than it would have been, with a resolution that's way better than it would have been had everyone not spoken up and had everyone's voices not been heard. And so I think this worked out pretty well. Another thing that was brought up by Tammy at this point was that really we needed to make it even more clear that if there's not a design review ready and that it just can't, that it just can't happen. So planning, I think this is a good point and we'll inform things going forward and the steps that are necessary to get merged. Lastly, before we talk about a little more on how to get involved, I want to touch on the power of the component maintainer. I think they're often ignored when the topic of decisions come up. I don't get asked about component maintainership very often, but the idea behind a component maintainer is that you commit to pay attention to a particular part of WordPress, whether that be the customizer or media or terms and taxonomies or the post section or whatever it may be. And however, they are also, I believe, the lifeblood of WordPress and the component maintainers making decisions and roadmaps are what help move WordPress forward the most. The important thing to remember is that everyone making WordPress does not know everything about WordPress. And so when I was making decisions, most of the time what I would do is just directly ping the component maintainers that were in charge of that particular thing and get their technical feedback, get their instincts, get their design feedback, and have it know from the experts, from the people who are actively working on it what the best route is. And so I'm going to talk a little bit about one example of when this happened during 4.5. So there's this feature in 4.5 that was ported by Constantine from Jetpack. And initially it was called SiteLogo. And it is a version of this did land in WordPress 4.5 and it allows you to upload an image and have it be your logo inside your theme. However, it went through a couple of changes, specifically due to component maintainer input. So pretty quickly afterward, this became ThemeLogo rather than SiteLogo. In Jetpack, this allows you to upload a single image and it would automatically be used across all of your themes. It was decided, however, after that feedback that this wasn't a great idea because the theme specified the size of the image and it's going to be different, maybe even a different aspect ratio for different themes. And while Jetpack has a workaround for this, Core doesn't. And so we'd be providing an experience that would not be a good experience for users. So it was decided instead to make it per theme rather than global. Very shortly after, the themes component maintainers talked to me and said, hey, we have this named wrong still. We need to change it again. It should be custom logo because in Core you have custom header and you have custom background. And so then that decision was changed and the final name is custom logo. And that's how it is in both in code and directly on your site. So finally, how can you be involved in WordPress decision? So if after hearing all this you actually still think you want to join or pay attention, then here are a few ways that you can get started. I highly, highly suggest becoming or sponsoring if you have a business that works a lot on WordPress, a component maintainer. All you have to do to become a component maintainer is show interest and show interest in that particular component by working on it. And then ask if you can be added to the list. Can you guess where the list is located? Make.wordpress.org. OK, that was really, that was really, that was pathetic. We'll see if we can do better on the next one. All right, so the other thing that you can do if you want to follow what's happening is follow make.wordpress.org. And there you can find information as well on how to attend the weekly dev meeting, which is where the various chats that I showed on here happen in Slack. So you can come anytime you want. So those are a few suggestions. And hopefully you learned a little bit about some of the processes involved. Please visit make.wordpress.org. All right, thank you.