 Good morning. Yeah, Noel kind of took away my entire trip, so that's two minutes at the link behind me. Yeah, I'm from Constance, so working to this one kind of special place on my mark is the second time that it was organized, right? It's my second time that I was invited or allowed to speak here. And I'm very excited to be here and I hope you guys start too. I am from a city called Constance. I feel like Constance is beautiful. That's how I describe it to all my friends, you know, when they ask where I'm from. If that doesn't look familiar to you, maybe that does. It goes to the Saturdays today, so I'm glad you're here and not at Constance. I appreciate it very much. But let's talk about WorkPress 4.3. The most recent release of WorkPress, which I have to be honest with you, it was the first time actually that I let anything in WorkPress. I've been contributing to WorkPress for about five years now. I'm really starting out getting more involved with the WorkPress project in 2012 when I started reviewing themes. Before WorkPress 4.3, I worked on mostly involved themes. So 2013, I think, had the most impact on. But I also helped out with 2012 and 2014, and a little bit with 2015, not too much. But the WorkPress 4.3 was the first time that I really led an effort within WorkPress. The main reason why I was chosen to be leading WorkPress 4.3 was because I had time. But it was great. And so to start out, I'd like to give you a quick overview over the timeline of WorkPress 4.3. It started out at the end of April with the initial 4.3 meeting. That was just a week after we had shaped WorkPress 4.2 at that point in time. Together with, I don't know if you remember that, around three security updates within like a week. So people were super burned out. And so for the first month of WorkPress 4.3, which was May, there wasn't really a whole lot of momentum going up until that point. It took almost until June. So we really had some momentum there. People got excited and started treating a whole lot more than they used to. We had a two-month period of ALTA, which is the period within the release, where we work on features. And we fix books and our pre-create in what we do. Then we had a beta phase, which lasted for a month in July. And in the beta, we just work on books and regressions that were introduced by work on features. We don't introduce more features to that. And it's kind of, you know, to make sure that we get ready in time for the release candidate phase, which started July 29th, with the release candidate being the software in a state where we think it is releaseable. Where we think it's in a state where we could ship it today. So the way we determine that is that basically by having a zero count of tickets, where there's no known bugs, there's no, I don't know, malicious reported, and if we fix everything by that point in time, we're ready for release candidate, which would work in actuality. WordPress operates on a way of creating features, we're building features for the software that we adopted about a year ago called feature plugin spread where we create features in a plugin first in order to be able to not be tied to a single release with a specific feature. Before that, we were developing features within a release, and that feature was ready a lot of the time, so we had to push back the release date in order to be able to pick that feature into the release. And now with, you know, as plugins, we can just continue working on them for as long as needed until they're ready to be merged into core. And for that to be determined, we had a merge window, which happened between June 3rd and June 17th. So it's like a two week window where we decide, you know, which plugins are ready for core, which can be, you know, merged into core, and then we have a two week window where we can actually do the merging. So that wasn't doing that, skip that before. Pretty much all the deadlines you see here, beta one through release candidate, including the target date for release to the work was 12.3, we hit. We, I think there was one where we were like two hours late, which fucked the hell out of me. Two hours. But anyway, some of that, we were on time, which I was very, very proud of, and released, worked with 4.3 August 18th pretty much a month ago, pretty exactly a month ago. And we didn't release a minor update to the PIX, but you know, we reported to a staff to release until this last week, which is actually a pretty long time. We usually shoot for like two weeks after a major release to, you know, release a maintenance update. But for that, 4.3 actually took us, or we were able to push it back a month, which is pretty remarkable in my opinion. So who again has not updated to 4.3 yet? Who are new? It's on an old WordPress version. One, two. Perfect. Awesome. Oh, come on you guys. That's great. For the two people who have not updated yet, I brought you the release video that we've created for 4.3. And if you have no other reason to upgrade, then these features, maybe they will communicate you to that. So I'll give you the release video. WordPress 4.3, Billy, named for jazz legend Billy Holiday, makes your writing workflow faster, your site easier to customize, and your password stronger. Let's take a look at how WordPress 4.3 is helping one small business owner. This is Kate, and this is the website for Kate's cafe, Shrodinger's Cup. Kate wants to provide a daily menu for her customers to keep them updated on what she's serving each day. This morning, she's going to make that happen right in WordPress. Kate's new daily menu page will tell her customers what she's brewing and what's for lunch that day. She wants to make her formatting nice and clear for her customers so they can quickly see what's on offer. In WordPress 4.3, she can change how her text looks without any clicks. Formatting shortcuts allow her to create lists, headings and quotes without breaking her flow. That keeps the task of publishing her daily menu straightforward and fast, leaving her free for the serious business of making coffee. Time for Kate to add the new page to the navigation menu on her sidebar. There's no need to go to the admin to do this. In WordPress 4.3, Kate can add her new menu item from the Customizer where she can live preview changes to her website before she publishes them. When viewing her new page, all she has to do is click Customize, select menus and add the new page to her sidebar menu. That wasn't hard. Now Kate's customers can check her website every day to see what she's serving. There's another new tool in the Customizer. Kate can now upload a site icon so that her logo appears in browser tabs and bookmark menus. Her customers can even create a shortcut on the home screen of their mobile device. Now they always have Kate's daily menu whenever they need it. And those aren't the only changes to WordPress 4.3. When Kate adds a new staff member to her website, WordPress will generate a strong password for them. If the staff member changes that password, WordPress tells them if their password is strong. That's enough WordPress for today. Kate's got a business to run. But she's happy that with every update, WordPress keeps improving. And she in turn could keep her customers happy, giving them the information they need right at their fingertips. There are things that didn't go as well. I grouped them down. First of all, I'm certainly involved in a lot of people, which is not really something that I probably could have influenced myself wildly in 4.3. But things I stood out was Betas and release candidates would need more testing. We had a big book in a terms plate feature that we also created in 4.3 that was historically late in the process, unfortunately, which also took almost the entire release candidate place to kicks, which was not ideal, of course. One of the reasons for that was because we didn't really have a way to do specialized testing for it, which is the second bullet point. And that is something that we should figure out for next time when we have a feature like terms plate to improve that. Pub scrubs was something that was usually only done by two or three people, right? There was hardly a time where there was more than three people who showed up to do some scrubbing of tickets and push tickets for it. And also we had a problem of a lack of movement towards the end of the cycle where a lot of the developers had other engagements outside of 4. And so it just kind of slowed us down and wasn't really something that really helped us move forward. Feature plugins, I mentioned those earlier, there was really not an obvious choice that was ready for 4.3, which is something that has been a problem for a couple of reasons now where future plugins are not in a state where they're obviously ready for 4.4. And it was also the case in 4.3. I hope that will be better in the current release 4.4 where there's a few plugins I think you'll hear about some of them throughout the day that might be ready for side icon, which was also used in the video before, should be done as a feature plugin. We pulled that feature out of Jetpack really and completely re-wrote it, right? And so it was really hard to do it as a feature plugin was a feature that was a feature fill-up if you want for 4.3. And also had four mentors involved much earlier, which had been better about doing in 4.4 where we had core mentors for the WordPress REST API plugin and also for Imageflow which is another feature plugin. And Omen I think is also one where we have a strong format for it. Involved you are in the WordPress community and the WordPress coverage and blogs and everything, but many customizers were certainly something that was one of the main digits in 4.4.3. It was certainly something that caused some controversy. And first of all, it was really controversy within the core team or people who contributed to the core, or rather people who work with WordPress don't direct the contributing core, but use the customizer and WordPress a whole lot for their daily work, you know, creating websites for people, maintaining their plugins, et cetera. So from a core point of view, a lot of people felt that many customizers wasn't complete before the merge method, which is the goal that has defined pretty possibly. All it says usually is that the feature plugin has to be ready and no one really knows where it is. So it has some leeway in both directions. And some people felt also that we relaxed standards to make the deadline with many customizer. So going forward, I mean, this has been something that has been an issue for a few releases where we kind of had to rush features in to make that merge deadline. And I think for a little bit, at least, that was also true for the many customizer, although I think it was pretty much correct. It was pretty popular. The merge proposal was the thing that kind of caused the controversy because in the merge proposal it said that it was a proposal out there. It was just a suggestion of people to give for, you know, this is how it's going to be. And the merge proposal said that we should remove menus from the admin entirely and only have them in the customizer. And that's what a lot of people felt very strongly about it. And I'm going to share with you some of the things that said it's pretty remarkable. Anyway, so you could have proofread that article, right? And something that brought it to a done. And it also could have been written in a different way where it would be more obvious that it's a proposal and not really set in stone. So some of the things that were said was merge seems more like a code DUI. Excuse me. Yes. Can you quickly, there's not a lot of tactics here. Yes. Can you quickly explain what feature plugins merge with? Oh, I thought I did. So feature plugins are, each of them I developed as plugins. And just like any other plugin you can activate and I'm excited that you can test it. So I'm going to put it on that plugin instead of working on it in core through patches, which also has the benefit that it doesn't have the bottleneck of the committers having to commit code every much anyone can help contribute and commit code to that plugin, right? And then merging is when we break code that creates the plugin into core, right? So we write, yeah, we would split up the plugin into the core architecture of code. Does that make sense? Yeah. Cool. Thanks for the question. That was awesome. Yeah, some of the things that were said about the mini-customizer. I believe the complete customizer should be flushed down the drain. It is very, very slow, very hard for this to work with. That's kind of crazy pants. Worst idea for this. It gets better. I'm embarrassed on behalf of these two developers. It's an absurd and immediate idea that should have never gotten into the customizer. Another wonderful decision by the team. It's nicely dictated to by people who don't care at all about the actual users. I'm starting to see how at least some core developers are becoming so arrogant and refusing to relay this to users. Where's the other? So this is kind of what we had to deal with. And we had to clean up. So we could have probably done that a little bit. Other things that didn't go as long, we completely changed features after beta one. That was something that happened with site hacking, which I worked on. And that is the truth. I wish it would have been possible to do that differently, but it wasn't. We had a big commit about 20 hours before the release, which didn't really go good. That is true. I wish we could have had a six day or week freeze to feel really comfortable about the release. And notes about the new features could have been written up earlier, which is more of a point of point. But what went really well? What went great before 1.3? Better passports, which was also mentioned in the video, right? Went really well. We had a great beginning of the release, outlining the way to better passports. People were asking us to keep our shortcuts. I don't know if you've experienced them. There's definitely time now. They saved me a ton of time already. People love them. Anywhere we show them at our work camps, people are super excited about them, and we only got started. There will be more that will be added to our quest. And also, a lot of people were happy with the list table changes. So we changed the list tables in the app and to work on mobile and had all the information on mobile readily available just as it does on desktop. You should definitely check it out. See if your mobile experience is better with our principle container. We had a pretty solid drop of guest emitters, which was L.A. Zoll, the Western Gallery, and me. All three of us, we worked on features that were part of the about page, so things that users actually saw between PsyLike and many customizer things. And the formative shortcuts, I'm sorry. We had that introduction on the formative component, which is traditionally something that is really hard to grow, because formatting has to account for a lot of edge cases. So formatting is everything that is taking a block of text and making quotes, curly quotes, for example. That is part of programming. And with a bazillion languages that it has to account for, that is pretty complicated. Touching small screen usability has improved significantly, which was one of the major goals of 4.3 in my book, and really was out of the way to publish that. And also shared taxonomy terms of it. This is an effort that has started in 4.2, where whenever there was two terms that had the same id, so if you have a category that is called PsyRIC and you have a tag that is called PsyRIC, those would be the same piece of data that it is. And we split those to be two different items, which they really are. And in 4.3 we kind of forced that split which is really something that is not trivial and had the potential to break a lot of sites, but we were able to do it in a way that it didn't. And so, yeah, a lot of people are disappointed about that, and it opens up the possibility for future improvements to taxonomies that people are very excited about. If you follow me on Twitter, I tweeted about this slide that probably mentioned the triangle. I'll tell you. I had it in college and I hated it, but now it's in my electronics. I can't believe it. But 4.3 was the software project, right? And like any other project, it had a defined budget and a defined scope and a defined time. And usually what happens in projects is one of those three things will not end up being in the place where it was supposed to be. So either you have to increase budget or you have to add more time to your project in order to realize the scope and quality that you're looking for. With 4.3 we were actually able to not do that a whole lot. I mean, budget or resources in that case is something that an open source project is something that you really can't plan with at all, because everyone is a volunteer. Most people are volunteers. So it was kind of an unknown and we had to work with what we had. We could just increase resources and just hire new people. That was just not possible. We had a set defined of scope, right? We had features that we wanted to include. And we certainly had a set time. We had the roadmap that I showed you earlier with the release date of August 18th. So, yeah, it was pretty much set and we were able to achieve all that without having to change a whole lot, which is super, super crowded. So the two things that I'm most proud of about 4.3 is that we shipped a stable version, a stable major release. I mentioned earlier that we had the luxury of waiting a month to release a minor update, which is not something that happens a whole lot. And I hope that this experience will increase the confidence in end users in our releases, something that I tried to do with 4.3. Very stable. I talked to some support forum volunteers who said that, yeah, the effort in terms of support has been more around a minor version update than a major version update. There was really not a whole lot of things that people think about or had questions about. And I'm super proud of that. But most importantly, we shipped on time. And I can't believe that we actually pulled it off. I queued about it. I think the schedule, and I said, August 18 is going to be the day we release WordPress. We did release some work with that on August 18. And I also hope that this is yet another thing that people will take and build more confidence in WordPress releases. I read some emails and some posts where it said, well, WordPress is supposed to release next week, but I guess we'll see if it really happens. And that kind of sucks. I don't want to read that, but it really sucks. We have that expectation already. Why do we do deadlines in the first place? So one of the philosophies of WordPress is deadlines are not arbitrary. And this was also one of my major goals with 4.3 to be able to say, we released some time, and I am able to say that. And I'm super proud of that. The next thing is, what's that? A clap. The one person clap that kind of much. The next thing was 4.3 for the first time had almost a million automatic updates. So most of you probably know we have automatic updates for minor versions, and you can manually set through a plugin or a constant encode. You can set it up so that every version upgrade will be applied automatically. And so 4.3 for the first time had almost a million automatic updates, which was amazing and led to a new record where we hit one million downloads to take a software in less than nine hours. 4.2, this is me by the way, I'm still over here. 4.2, it took just over 24 hours to hit one million downloads. And 4.3 was in less than nine hours, so I'm pretty sure that we will easily top that with the next update, 4.4. My name is Konstantin Obenland. You possibly saw my two right-hand one slides at Obenland, and I find myself worth overlying to the followers. So 5.3 for all of me. I believe that I blog also at Konstantin.obenland.com mostly because I'm not good at writing, but they are interesting. I work at Automatic. My title there is Releasely Retired. I've been there for years. I work on a team that is dedicated full-time to returning to WordPress 4 and the work with the WordPress section. And this is it from me. If you have questions, I think we have a couple minutes for questions. I have a first question for you. How does someone in this room, which has just limited development experience, they work with small websites, medium-sized websites, things like that, how do they come tomorrow and start contributing to the core or to theme reviews or whatever, how do they feel comfortable about it? Because we still have a few spot spots, so we're more than welcome to come. Great plug. Awesome. Yes, so if you can read or write, you can contribute to WordPress. I assume most of you guys are going to do that. There is a vast difference in skill sets of people who contribute to WordPress. You cannot only contribute through code to contribute to WordPress 4, but you can also, as Bill mentioned, you can review fields. You can write plugins and put them in the repository. That is something that you can do contribute to WordPress without really contributing to the project. Documentation is something that needs a lot more volunteers than we currently have to document the code that we have to document processes. That's why I said that if you can read and write, you can help us out. There will be a lot of volunteers tomorrow who can help you get involved, and all you need to do is really just show up. Another thing that you can do is translate. Most people here speak more than one language right now, so this is definitely something that most people here probably do help translate WordPress plugins, themes for other users. We just recently launched localized plugin and theme repositories, so there is a huge demand of translation work right now so that those supposed stories can be offered in local languages. Yeah, tons of other opportunities. Just show up, please do. I'll just say there's more room, and I think there's pizza, is that correct? Free pizza, come on. That can be repeated. Yeah, just a question about signing up for that. Do we need to sign up? No? Yes. It's at the bottom of the schedule you can sign up for distributed it tomorrow. Please do. So the question was, he said that he usually waits a month for the minor update to upgrade to an inversion. How do we ensure quality? Is that correct? So, WordPress 4.3 wasn't accepted, of course, but it's very stable. How do we ensure quality? That's a very good question. We have, well, in 4.3, in that case, we had four weeks of a beta fix and then an additional three weeks of RSC, so we had seven weeks, almost half the release, so we only spend on fixing bugs, testing the hell out of the new features that we have, and making sure that they're as stable as possible. Of course, we are dependent on outside testers, on people who also test in their environments. Without that, we can only do so much, right? One of the things that keeps holding us back is that a lot of people only start testing when we hit the release candidate phase because they don't do the necessary or worth their time to test it, which really, really slows us down and increases our go towards the end of the release, which is not ideal, right? Ideally, we'd have those reports in the database where we can address them much quicker than in RSC. So we rely on our testing. We have a big unit test suite now and WordPress for both PHP and JavaScript, which we rely on heavily in the meantime. Future plugins also are not merged without unit tests. They also need user testing for user experience purposes, and they need to be as bug free as possible. So we have another quality gateway right there when we merge future plugins in. Ideally, of course, there's always bugs that are unforeseen. But these are all measures that we take to make sure that the releases are as stable as possible. And I'm pretty sure that this is also something that we'll continue to get better as we move along. I think 4.2 and 4.1 were pretty stable releases. 4.3 obviously too. 4.2 had a security update coming out pretty much like a week after it was released, which was unfortunate. But in itself, it was very stable release, and I think the first maintenance group wasn't until three or four years later as well. Is that good? Thanks for your question. One more? Yes. What about security? Is it so hard to do the core of the work itself of the public directory? Is it hard to do the... Is it so hard to move it out of the public directory to ensure security? Because it's really the biggest issue of the work. It's all between all the other files inside the site itself. So all other frameworks can be pulled out out of the room. That is a good question. I know that you can pull out the content folder and you can pull out WD conflict, first of all. And I'm pretty sure that with the right permissions, you're pretty safe when it comes to the files. I'm not a security expert, unfortunately, so I'm not sure I can help you a lot with that. But I know who could answer your question and I'm happy to connect you later on. Is that an acceptable answer? Thank you. All right. Thanks so much. I'm done for today. Actually, it's not through. I have another one coming up, right? I'm not done for today. Thank you very much. I'll see you later.