WP Briefing: Your Opinion is Our Opportunity

In this episode, Josepha discusses the importance of co-development and testing for the continued growth and maintenance of the WordPress project. 

Have a question you’d like answered? You can submit them to [email protected], either written or as a voice recording.

Credits

References

Transcript

0:10

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!

0:39

Prior to Gutenberg, our current multi-year project that is changing the way we see WordPress, another multi-year project changed the way we saw WordPress. Starting in 2008, substantial changes to the WordPress interface came in a series of major releases, starting with WordPress 2.5. That was before my time in the project; I’ve only ever worked with the current dashboard in WordPress. But, from what I’ve read, the user testing that would have gone into it was a huge undertaking and very well coordinated. Now, WordPress has not taken on that type of robust testing project since, but starting around 2014 or 2015, a community testing practice was started. I’ve shared these calls for testing frequently, both on Twitter and in this podcast. But you may not really know why I find the testing program so valuable. So today, I’m going to explore with you the concept of co-developers in open source.

1:52

Open source software, like WordPress, is built by the people who show up. There are a few obvious groups when you think of software, the developers, designers, technical writers, folks who monitor the forums, and really, all the teams you find in our WordPress project. Co-developers or co-creators, if you’ll join me in making our tent a little bigger, refers to the users of an open source product who actively engage and contribute to the work by using the software and sharing any bugs that they find.

2:25

I mentioned this group in the episode about how WordPress improves. Specifically in that episode, I underlined that if you consider users to be part of the collaborative process, as long as people use your product, those people will have opinions about your product’s needs. And today, I’m extending that thought a bit further to say that, as long as there are opinions, there are opportunities.

2:51

When you know what isn’t working, you can focus your attention on a solution, you can focus on making sure that you can make it work. The existence of co-creators is one of the great things about open source. No designer or developer or product owner has to know every sort of user to be able to get feedback from them. If they show up, test the software and get their thoughts written down, then you can start to see patterns and common pain points. It is also, unfortunately, one of the great difficulties of being an open source project. After all, if users don’t show up, or don’t test, or don’t write down their feedback, it’s impossible to know what worked for them and what didn’t. And on top of that, with such a large percentage of the web being supported by WordPress in this case, not every problem is part of a pattern. And not all patterns are part of the current priorities.

3:54

Looking beyond that double-edged sword. Let’s say that this idea of a co-creator makes sense to you. And more than that, you feel like it describes you. What does it mean for you to show up in WordPress? There are lots of good ways to offer this sort of feedback and contribute to those patterns that can help us see through the fog. So I have for you a mini list and, of course, a bunch of links in the show notes for you. 

So some good ways. First, you can participate in any of the dedicated calls for testing. They are short and frequently have a guide. I participate in them and generally find them fun. I say generally because sometimes I also find them frustrating. That’s really okay too; the frustrations helped me to identify that I found a problem. And if I can find a problem, then I have saved someone else from finding that problem in the future. The second thing you can do is file a bug report with information about what happened when you ran into a problem and how someone like me could make your bug happen on their site. Bug

5:00

Reporting is one of the things I’ve grown to really love in my time and open source; I did not love it. At first, I was really scared to do it. I mostly used to send videos of the bugs that I found to other people and ask them to file the bug reports for me. But then, of course, I never knew whether they got fixed or not. So I was scared to do it at first. But once I figured out what makes a “good report,” I felt like I was helping circle hidden treasure on a map or something. I realized also not everyone’s excited about finding hidden treasure on a map. But I play video games and finding hidden treasure on maps is, like, a thing.

5:43

A third really great way to contribute like this is that you can join any community meeting to learn more about what’s happening now and in the future, or just to see what makes WordPress work. As a heads up, these meetings go really fast. And they’re all in text. And there’s sometimes, but not all the time, a little bit of jargon that you have to head to your favorite search engine to find. But I sit in on about half of them myself and get a lot of really good information about things that I’ve been wondering about, things that looked broken, but actually are functioning exactly the way that they should. And I just didn’t want them to function that way. And more often than not, I found out that something that I thought was broken, was already identified and being fixed. Those are three great ways to show up and help give feedback that helps make WordPress better and more functional for more people. 

There are also a few other ways that we see people trying to share that feedback that don’t work quite as well. And I’m going to touch on a few of them just because it’s important to know, as you’re trying to figure out how to get started with this. The first one is just tweeting your frustrations, and I get it like that’s literally what Twitter is for.

7:03

But also it’s hard to create a block from “I am frustrated, behold my hateful rhetoric.” Not that any of you, my dear listeners, ever tweet hateful rhetoric. Still, that is really hard for anyone to figure out what was actually wrong in that moment. Another thing that is not the most functional way to give feedback is review brigading. The Internet rewards this kind of behavior, but I have found at least for WordPress, those false positives and false negatives can be really confusing for our new users. And the third way, that’s not our best way, and probably is the least best way, is just by giving up and not telling anyone what broke for you.

7:45

I know that I already said it’s not possible to fix everyone’s problems. But while it’s not possible to fix everyone’s problems the moment they get shared, it’s also truly impossible to fix any problems that no one knows exist. And so giving up and not sharing an issue so that we can identify it as part of a pattern of problems is probably the least effective way to help us help you get your problem solved.

8:13

This brings me back to the question of the value of WordPress users as co creators in the development process. As WordPress grows, both in usage as a CMS and in participation as a community, it’s important for us to shed the idea that software creation is only about what literally can be done to code or what literally can be done to core or what literally can be done to the CMS. It’s also important for us to constantly remind ourselves that the best outcomes are the result of collaboration with the people who use WordPress the most. I know that not every type of user we have is showing up to give us feedback about where WordPress doesn’t work for them. And I would love to see more feedback that helps us to figure out where our patterns are.

9:03

So the bottom line is this without user feedback that has some clarity of what was expected versus what happened, the work to make a good choice involves a whole lot of guessing. So since open source software is built by the people who show up, I hope this gives you an idea of how you can show up and help improve the tool that powers your sites.

9:32

That brings us to today’s community highlight every episode or so I share either a great story of WordPress success or a great story of a WordPress contributor who helped some folks along the way. Today’s community highlight comes from @trishacodes who shared one of her early to WordPress mentors. She says “@RianRietveld was such an encouragement and helped me find the courage to speak up.” I have had myself many conversations with Rian, and that rings true for me as well. 

10:00

That brings us to the moment you’ve all been waiting for, the small list of big things. It’s actually kind of a medium list. Today, I’ve got four whole things to share with you all. The first thing on my list is that WordCamp Europe is coming, that will be June 7th through the 10th. It’s a multi-day online event. I will share in the show notes a link to the main website; there you can get an idea of what will happen, the schedule, and get your hands on some tickets so that you can get it in your calendar and prepare yourselves. 

The second thing I want to share is for all of our polyglots out there. The French team is planning a translation day coming up on April 30. I will share a link to that as well so that you can get an idea of what that takes if you’re feeling like you want to do some translation work. The third thing I want to share is that the Indian community in Pune actually started a new meetup series. It is a translation work along self-study – also for all of our polyglots out there. I would love to see as many people as are interested in both learning about how to do translations and certainly translating WordPress get registered for that. A final thing I want to share with you all is that if you are curious about what full site editing features will be included in the 5.8 release, that’s the WordPress release that’s coming out in the middle of July, you can check out my recap and recording of the demo that was held with Matt, Matias, and the rest of the team. There’s are also a number of other posts of next step ideas that I will share in the show notes as well.

11:51

That, my friends, is your small list of big things. Thank you for joining in today for the WordPress briefing. I’m your host, Josepha Haden Chomphosy. I’ll see you again in a couple of weeks!

WP Briefing: Who Is WordPress?

In this episode, Josepha explores the five groups within the WordPress ecosystem and provides a high-level example of how they interact and support one another. As always, stay tuned for the small list of big things and a contributor highlight.  

Have a question you’d like answered? You can submit them to [email protected], either written or as a voice recording.

Credits

References

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!

In the first episode of this podcast, I said that there’s a lot that goes into WordPress, that’s really hard to see. One of the hardest things to see about the WordPress project as you get started is the overall structure. There is quite a bit of documentation that can clarify the basics: the names of teams, what they work on, and where, and when they meet. The way that they influence and support each other can really feel like a bit of a mystery. So today, I’m going to break down the WordPress community into five big groups; I want you to keep a couple of things in mind. 

Firstly, these are high-level and based on my observations. Each of these groups can be further broken down into subgroups. So while you may not feel represented in this exact five, you are included if you were to dig a little bit deeper. The second thing to keep in mind is that the makeup of these groups is pretty fluid. Many community members find themselves in more than one group, but generally not far off. Some group two folks end up in group three, depending on the situation, people in group four can also end up in group five, and so on. As with so many things that I share, I’m not trying to insist that one size fits all. I’m not trying to put the WordPress community into a box. This is just a basic framework to understand how it all fits together. Alright, are you ready? I’m ready. Let’s do it!

Okay, I have a broad definition of the community, which I have mentioned before. I believe that the community is anyone who has interacted with WordPress, whether they know it or not. So, I’ll start from way out there and work my way in that first group; we’re going to call our Visitors

Visitors are people who arrive at a WordPress site to gain information or engage in an activity. Sometimes they know it’s a WordPress site, but most of the time, they don’t. The second group are Users, people who use WordPress as their CMS. So, that’s website builders, website designers, small businesses, content creators, and the list goes on and on. The third group I like to refer to is the Extenders. Those are people who extend WordPress through the creation of blocks, themes, plugins, and more. There are also people who teach WordPress to others through WordPress podcasts, and newsletters and tutorials. The fourth group I refer to as our Contributors is the people who contribute to the open source software and the infrastructure supporting it, but not necessarily the same people who contribute directly to their own product. And then there’s group five, Leaders. Those are people who help drive the vision and strategy for WordPress; the most notable member of that group is of course, Matt Mullenweg. And I’m also in that group. 

Each of these groups directly influenced the groups on either side. For example, a WordPress user is affected by both visitors and extenders. Imagine a content creator who shares their passion for photography through a WordPress site; this photographer may have visitors that need to purchase photos. In response, the user now has a need to make it possible for visitors to purchase photos on a site. So they go to what we consider the extenders, people who have built a plugin that supports that need. And as a result, that user can install that on their site. And they have have satisfied the need of the visitors to their site, the people who now can purchase photos. 

There are a lot of examples like this in the WordPress project. Every small pattern that you see is mirrored in the larger patterns across our ecosystem. And every large pattern you see in the ecosystem can be seen among our teams. It’s pretty cool to look at really. So, why should this matter to you? From a very practical standpoint, this matters for anyone who’s trying to learn more about contributing to the WordPress project. These five groups mirror very closely the five steps of volunteer engagement that we see across the ecosystem and from a more philosophical standpoint, it’s just kind of nice to know who your neighbors are. Without the influence and support of the groups around us, it can be hard to know whether we’re on the right track or not. So take a look to your left and look to your right, and get to know your partners in this project.

That brings us now to our community highlight, the segment where I share a note about contributors who have helped others along the way, or WordPress success story. This week’s highlight is from @CoachBirgit, Birgit Olzem, a longtime contributor and a friend of mine. Her success story goes like this. 

WordPress has allowed me as a mother of five to leave a toxic marriage for good. 

Later, the community picked me up when I became seriously ill. 

So I can say from the bottom of my heart, that working with WordPress has saved my life.

And now our small list of big things. I’ve got three things for you this week. I think that they’re all very important. And I hope you check them all out. The first one is a reminder that word camp Central America is coming up on April 15 and 16th. If you have not registered for tickets, you still have time, I will share a link to the registration page and the schedule in the show notes below. 

The second thing on our small list of big things is that the Gutenberg 10.4 release is coming out later this week on April 14th. It’s an important release because it’s when we take a look at the current iteration of full site editing tools that we have, and decide if it’s ready to get into the WordPress 5.8 release. There’s a post that has a little more information about that which I will share in the show notes below as well. If you haven’t checked out the Gutenberg plugin lately, obviously I think it’s a good idea to do that in general, but definitely a good idea to check it out now. 

The third thing on our list today is a reminder to check out our most recent block pattern tutorial, I’ll share a link to that in the show notes. It’s this kind of tips and tricks, tutorial, the “show me how to do it,” kind of thing in the style of CSS-Tricks. If you or anyone that you know might be interested in sharing a similar style of tutorial, there’s a link to a form in that show notes as well so that you can share with us your name and the topic that you’re interested in. We’ll take a look and see if it’s something that we definitely need to make sure our users know how to do. So, that my friends is your small list of big things. 

Thank you for joining in today for the WordPress briefing. I’m your host, Josepha Haden Chomphosy. I’ll see you again in a couple of weeks!

WP Briefing: Talking Full Site Editing with Matías Ventura

In this episode, Josepha is joined by Matías Ventura, also known as “the spark behind the vision of Gutenberg.” Josepha and Matías discuss full site editing and answer your questions, from “is full site editing a standalone plugin?” to “will full site editing break my current site?”

Have a question you’d like answered? You can submit them to [email protected], either written or as a voice recording.

Credits

References

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!

Josepha [0:41]: This month, we have a bonus briefing, so I’ve asked my dear friend and colleague Matías Ventura to join me. Matías was recently called “the spark behind the vision of Gutenberg.” With full site editing coming our way in 202, I asked if he would join me for a quick Q&A. Welcome, Matías. 

Matías [0:56]: Hello, hello! Thanks for inviting me. It’s a pleasure to be here.

Josepha [1:00]: Well, I’m delighted to have you. And I think that we have a lot of excellent questions. All right, so Matías, we actually ended up with questions in about three different groupings. And so I’m going to start with the “what is it about full site editing,” sorts of questions that people had. We’re gonna work our way into “what are we doing with it?” and then “how are we planning on getting this out the door?” Then, a couple of big picture questions that people asked. We’re just gonna leap right in this full site editing part of the Gutenberg plugin, or is it a standalone plugin?

Matías [1:39]: Okay, we’ll start with the basics. Full site editing is part of the Gutenberg plugin right now. I think it’s important to mention that full site editing is like an umbrella for several projects that we’re working on. They are all aiming to bring blocks into more parts of your site so that editing becomes easier and more expressive, and so on. So full site editing right now encompasses adding a ton of new blocks. I think we have around 20 new blocks coming in, including navigation query, site, title, logo, etc. There’s also the interface to interact with templates outside of the content; that’s another big part of the full site editing project. We also have a lot of new design tools included, many of these have been released in previous major releases, but they still comprise a strong part of what full site editing is. We also have something called Global Styles, which aims to allow people to configure the visual aspects of blogs across the entire site, not just on any individual blog. And of course, then there’s a whole layer of how we utilize these tools. It can get complex because there are many layers and projects that need to come together. So yeah, all of these are accessible through the Gutenberg plugin right now.

Josepha [3:07]: Yeah. So it’s not a standalone plugin. If you wanted to check out full site editing the site editor experience as it is now, you would just have to make sure you had the Gutenberg plugin on your site. Right?

Matías: Yes, correct.

Josepha:  So a couple of the questions related to this are how exactly do I enable it on my site? And what is the easiest and safest way to try this on my site? And I think the answer is, is right in there. It’s in the Gutenberg plugin. And so if you have that plugin, you don’t need the testing plugin or anything else to make that work, right?

Matías [3:51]:  No, you like, you might need to install a theme like Twenty Twenty One blocks that unlock some of these new interfaces that we just talked about. Like other of these pieces are available for anything. But some of these, like the interface to edit templates, right now only talk with things that know how to express their desire. 

Josepha [4:14]: And I think we have less than 10 themes right now that do that, but I’ll leave some links to at least 2021 blocks in the show notes. And then, if there are another one or two themes that I can find, I can add those in there as well. 

So you have to have the Gutenberg plugin; you have to have a theme that works with that site editor kind of experience. And then you’re safe to try everything out. It shows up in your left toolbar just like any other thing, like if you were working with plugins, or if you were adding a post or anything else, right?

Matías [4:51]: Yes, correct. And so, some of these details are being worked on right now. Like how and where you access things, and so on. These things are subject to change, but right now, you have this site editor beta in the sidebar when both you have the plugin running and a theme that’s capable.

Josepha [5:10]: Yeah. Excellent note. If you are running this on a production website, I would recommend you not do that unless you are very, very good with WordPress. It’s a really safe and easy thing to test and try out. But because it is still in beta, I recommend always putting it on a test site. I have a couple of different test sites that I run on myself. Another question that I had was, “will full site editing slow down my site?” And I think we have some refreshed performance tests coming out about that. And maybe they’ll be out by the time we publish this podcast.

Matías [5:49]: Yeah, I mean, like the performance has been one of the major focuses for the whole project. In many cases, it should speed up things because we’re like, I think one of the big pieces that these projects bring into the picture, especially for themes, is that it allows only the necessary assets to be loaded on the front end. For example, if for a given page, there are, I don’t know, 10-15 blocks being used, you would only get the CSS and scrapes and so on related to those blocks. This can cut down on a lot a ton of CSS that themes used to end queue on a side, particularly if you were trying to customize many widgets and so on, like a lot of themes have the full styles or multiple widgets, even third party plugins, and so on. So one of the advantages of having this blog system is that we can know at the time of rendering what blogs are being used and only load those assets. 

Josepha [6:50]: Excellent. Another big question that we have is, “does full site editing work with the classic editor? And does it work with other builders?” I think that’s a really big answer if you’re going to get super deep into it. But I think that the short answer is yes, it does. Is that fair?

Matías [7:08]: Yeah, I don’t think it touches a bit on that full site editing is not like a single thing. There are multiple projects around it. So again, like the template editor that only deals with blogs, it doesn’t have a lot to do with a classic editor. But the classic editor use for both doesn’t change anything at all; like the same way that when the block editor was introduced, it didn’t change how you could still write posts in the classic editor. You will still be able to do that.

Josepha [7:41]: And if you are brand new to WordPress person, or, I mean, I guess at this point, you don’t have to be super brand new. If you’re fairly new to WordPress person and have no idea what we’re talking about when we say the classic editor, you don’t really have to worry about it either. You don’t have to go and find out what that is; the block editor that you have right now works perfectly for what you’re trying to do. So if you don’t know what I mean when I say classic editor, don’t worry about chasing it down either. 

I think that this last question we accidentally answered earlier, but I’m going to go ahead and ask it anyway since I received it. “I keep hearing that you can use the site editor with the 2021 theme. But I don’t seem to be able to. What am I missing?” I think the answer is that there’s the Twenty Twenty One theme shipped with the WordPress release 5.6. And then there is the Twenty Twenty One blocks theme; those are two different themes. The link to the Twenty Twenty One block theme is going to be in our show notes this time around. And so, if you have been trying to use the full site editor with Twenty Twenty One and not succeeding, try the link to the one below. And I bet that that will work for you.

Matías [8:50]: Yes, that’s correct. 

Josepha [8:51]: All right, excellent. Well, that brings us kind of into our second set of questions, which is about how we are doing it. The first one that folks have is “will full site editing be on by default in the next release. In this context, the next release is WordPress 5.8. But I think it’s a safe question to ask if full site editing will be on by default in the release that it’s planned for.

Matías [9:15]: Yeah, and for this, I need to go back to the same principle of many projects because there are many pieces of full site editing, and we have been merging them in major releases, particularly like the blocks and the design tools. There are more coming in that we want to make accessible as soon as possible. The full experience that requires a theme to opt-in to templates using blogs won’t be by default; it requires a specific theme running. A lot of these details we’re still like determining exactly what projects are ready to be merged and so on. But yeah, if you have a theme right now that works the way you want, it doesn’t change anything there. If anything, it adds some more capabilities and more customization tools, and so on. And the theme can also regulate how much they want to incorporate.

Josepha [10:13]: Matías, you’ve mentioned a couple of times in this podcast so far like this is a really complex and really complicated part of this work. And just for anyone out there who’s either encountering Gutenberg or full site editing or this podcast for the first time, I think a tiny bit of context that’s worth having here is that Matías and I have been working on this together in various capacities for like, five years. And Matías has probably been working on this for practically a decade. So, when we say that this is a really complicated problem, and when we say that this is a complex set of issues that we’re working with like, it is all that we have been thinking about for I want to say at least the last three or four years, but certainly it’s all that we have been trying to untangle for quite a bit of time before that as well. So we don’t take it lightly when we’re like, “this is complicated;” we mean it. It’s really complicated. And we’re trying our hardest over here as WordPress. 

The next big question, since we’re all stuck in the “it’s very complicated,” part of things is the question, “will this update break my current site?” Like, if I have a site that is updated and ready, and it’s exactly as I wanted it to be, and it took me two years to get there will full site editing, whichever release it’s in. Currently, 5.8 is what we’re planning for. Will that break anything on my site as I know it right now?

Matías [11:44]: No, not at all. One of the major things that the WordPress team, the WordPress community, always cares so much about, never to break things. Many of these things are stepping stones that you can adopt, as we’ve talked about full site editing. But for example, we also have a few concurrent projects around the widget screen and the navigation screen that are meant to bring blocks into existing interfaces. So again, the theme doesn’t need to change, and a lot of care is being put into making this more like you’re unlocking new features, and nothing really breaks or falls apart.

Josepha [12:23]: This update, like all the other updates, should have minimal, minimal impact on what you have to actively fix on your site. Every once in a while, a bug is gonna get by. We can’t say that we’re 100% perfect with not breaking things. But also, we always and I and I know that we’re planning on this for our remaining releases for the rest of the year. At the very least, I can’t imagine we’d ever change it. But after every major release, we always make a plan to have a minor release within the next one or two weeks. Because we know that a broken thing on a site is really incredibly impactful, even if you’re only 1% of the sites that had that happen to it. And so I think that’s true in this case, too. And getting that feedback back from all of the people who are actually using WordPress is the thing that makes us be able to kind of move quickly when we do see those problems. 

One of the questions that we have been getting is, “can I see a live preview without saving the changes that I made?” When I got this question, I didn’t actually understand it. And so I went and looked at a site without the Gutenberg plugin on it, and then a site with the Gutenberg plugin on it. And of course, on sites without Gutenberg, without the block editor, without full site editing, when you are looking to preview, you have the option to open up your preview in a new window. And you don’t have that with Gutenberg because it’s supposed to be a true WYSIWYG editor. A true what you see is what you get, editor. I think that the answer to this is, yes, you can see a live preview without actually saving the changes on the front end of your site. But you don’t actually have to reload anything. You don’t have to open it up in a new window. You don’t have to, like, actively click “please show me a preview” because what you see in your editing screen should be what you see at the end of your app as an end-user.

Matías [14:28]: Yeah, that’s the sort of the main gist to it. Yes, the site editor is built so that it always reflects the front end as truly as possible, so that’s one layer. Also, the preview tools should allow you to see in different devices like mobile breakpoints, and I don’t know if they will have breakpoints and stuff like that. There are a lot of things in the current interface that is just not enabled. There are some challenges in the sidebar. Because the site editor is not just focused on a single post, it’s focused on the entire site. So, there can be many, many changes that need to be shadowed for the site. 

If you’re changing the site title, some of the global styles, aspects, and so on need to be orchestrated. So, to see in the previewing new window, there are some challenges there to integrate. Again, the interface is not final yet; a lot of these things are still being tweaked and improved. There are many things from the regular post editor that are not enabled yet. But they will be enabled. So yeah, it’s a, I guess, it’s not a simple thing to answer. Because, again, the idea of previewing the site that’s core to the whole project is that you’re always interacting in the same way that when you’re in the customizer, you’re seeing the preview all the time. That’s the main scope of this project,

Josepha [15:54]: Excellent. Changes like that changes to your workflow can be really hard to get your mind around, especially if part of that existing workflow was there to create some confidence in what you’re seeing with your users. And so I understand. Now that I’ve researched that question a bit, I see where that’s coming from. Based on existing workflows and existing patterns that we have for ourselves in WordPress, will we need to have a theme to use the full site editor?

Matías [16:33]: I think we’ve already covered some of these. And again, they are tools that can work on any existing theme. There is other stuff that needs space-specific themes to opt-in into these tools, like blog templates and so on.

Josepha [16:50]: Yes, I think the question that we have next, because I see that the literal next question I have is actually something we have covered; just because we’re being pretty conversational about it, not because anyone already asked the question. So I’m actually going to skip to the last question of this section that I received. I got this next one via Twitter. The question is, “how do you view the role of themes once full site editing is fully rolled out and all the page elements (content, headers, widgets, footers, etc.) and all the views are managed via blocks and block patterns? Will things become typographic and block styles?”

Matías [17:28]: I think this is a great question because it goes to the heart of, why are we doing all this. One of the main reasons is to empower users more. WordPress has been democratizing publishing for a while; this is another step into allowing themes to get more customization tools and more control over their site if they want to. I think the recent call for testing has focused on the 404 page, for example. That’s something that forever has been locked away from users. And it’s also something that, as a theme developer, and I used to develop themes a long time ago, that was one of the things where you decide what sort of approach you take for the 404 page. Maybe sometimes you want to have something more whimsical. Sometimes you need something more serious. And committing to one when you can have such a diverse and broad user base can be challenging. With these, it becomes as easy as offering a few different patterns for that template. Then the user will always be able to change the copy and modify something. So again, it opens up a lot of these things that used to be locked down. However, from a theme perspective, I think this doesn’t reduce the theme at all. If anything, it allows the theme to focus less on coding and functions and more on design expression and aesthetics. I don’t think that would ever be exhausted. That will always remain as diverse as humans are interacting with WordPress. And so it’s not that I don’t see it’s just as like, typographic and block styles. How do you express a template, how do you express the structure, what choices you quote, what choices you make as a theme builder? And of course, there are many degrees of control there. Because a site maintainer may not want the 404 template to be editable, that sort of control will always be present.

Josepha [19:38]: Yeah. And really fast. I have to add a caveat to a thing that you said in there. For anyone who’s listening keenly, you may have heard Matías say that the users can update any of the content there – any of the copy. In this context, we’re talking about users as in the people who are maintaining the site, not people who are visiting your site. Visitors to your site will not be able to change any copy on your page unless you’ve done something very interesting with your WordPress site, which is also fine if that’s what you prefer to do. By default, your visitors can’t change everything on your website, which is good news, frankly.

So I’ve got one logistics question, which I’m happy to take. And then one is kind of a big picture question that I also got from Twitter. “What about the classic editor block; what is going to happen to that? And when will we know?” So ages and ages ago, before COVID? I think so. Probably maybe a couple of years ago, Matt said that the classic editor plugin would be supported through the end of 2021. And that is still the case; there will be active support on that through the end of 2021. After that, it will not be actively supported anymore. It won’t be removed from any place that you can get access to right now. In a “this is the end of its lifecycle” sort of way, we just won’t have anyone who is currently committed to maintaining that plugin anymore. So that’s what’s happening at the end of the year. And yeah, at the end of 2021. The big question that we have is, “why is full site editing being so rushed?” I think this is a bit of a loaded question.

Matías [21:32]: Yeah, I think I think it’s still a fair question, though. I think we’re dealing with two things here. And one is ensuring that we release things in the best state possible. And also, some of the urgency is to offer tools that we know that people lack right now and that could really benefit from. Making that determination is very tricky. The full site editing project has been in the works for the last couple of years. If we count the initial phase of Gutenberg, that’s four to five years. We’ve been doing many calls for testing, which I think have been super useful to catch issues and reflect as a community on where things are going; how do we integrate with these? How do we use it? What are the shortcomings? What do we need to do? Based on all of these, we’ll continue to make decisions on when things become ready. We’re not committed to releasing something that’s not in a good state. And I think we will always be very careful about that. There are these two competing senses of the urgency – of getting some of these tools out, and because it also benefits from the feedback loops. I always say that, in many ways, the initial phase of Gutenberg, to me, is not finished. We took the initial two years to do the 5.0 release, the initial block editor, and so on. But, it’s still being improved at a very fast pace, among all the recent major releases improvements to the editor were included; that will continue to be the case. In many ways, phase one is not finished. And the moment we choose to release some of these tools or editing tools, it won’t be finished either. They will need to continue to grow, mature, and incorporate a lot of the feedback. Even the things that the ecosystem is building around. I’ve seen a few themes already that are incorporating a blank canvas template so that you can use them in some pages and take over and do everything with blocks. So even the community and ecosystem as a whole is also sort of paving the way for what needs to come.

Josepha [24:06]: I think from my perspective, and of course, I’m on the people side of things, the communication side of things, the logistics side of things; I have a frequently a very different view from what a lot of other folks are seeing. And so from my side of things, I have to say, I’m communicating about this change in a really broad way, which has not been happening since 2019 when we started the work. We’ve been communicating broadly with the WordPress community, but not with everybody who uses WordPress. So, I think that for a lot of people, this looks like a project that we started really actively working on in the last six months or so. And now we’re just racing toward a finish line. I think that there’s, there’s not been a lot of awareness of everything that’s gone into it. And so, on the one hand, it feels a little less rushed to me knowing the full length of the history on this. But also, as you said, I really think that this gets a bunch of tools to people who otherwise have not been able to accomplish these things in WordPress or otherwise. I am so anxious to get something to people who really can benefit from this change the most. And it’s the nature of the open source, right that like, one, as long as you have users, you’re going to have stuff you have to fix in your software. So we’re never really, really going to be done with this; there’s not going to be like a done point of WordPress. And the second thing is, I think it’s generally true that you don’t really start getting full user feedback until after you have launched your major release. I think that we see that a lot in open source software; you can bring in as many people as you think you can in your user tests heading up to it. And in your accessibility tests. And, in general, quality assurance tests. You can bring in a lot of people and still not have gotten the full understanding of the various niche use cases that your users will bring to you. Because at this point, we’re like 40% of the web. And that means that we’re serving this majority collection of increasingly minority voices and niche voices in the space. And so, a little bit I feel a sense of urgency; I feel a bit of anxiousness about trying to get this out there for one, to get the tools in the hands of the people who can benefit the most from them, but also so that we can start really getting the full stress test of this software out and get that feedback in so that we can really build something responsive to what our users need our long tail, “anyone who ever uses WordPress ever,” definition of users. And so, that’s why I feel a sense of urgency around it. Even though you know, as I said, you and I have been working on this for like five years, and you’ve been working on it for a decade or something. I actually don’t know how long it’s been worked on.

Matías [27:35]: Now that makes me feel a bit old.

Josepha [27:40]: Nobody makes Matías feel old. He is a lovely, wonderful colleague. Sorry, Matías, If I made you feel old.

Matías [27:46]: No, that’s totally fine. I also want to add that full site editing is not like a single toggle that’s going to drop into a major release. So I think that’s important to consider, I think this entire year is going to see a lot of these tools being, and sometimes the sort of the end-user is not the, again, the site maintainer. Still, you can also be the theme developer; I think there are many tools that would be empowering for theme developers to use. Again, we mentioned there are like five to ten themes, block themes right now. That needs to grow a lot, and that only grows through these sorts of feedback loops. And the theme community pushing things forward and seeing where things can lead to. I’m very excited about the pattern directory integration because I think that can also combine with blog themes in very powerful ways. Imagine if, I don’t know many of these patterns that are very common on the web and very needed, that if we can refine them together with a second community and make them available across themes, you can combine a header from one theme with a content of another; all these sorts of mixtures could happen. All of this needs exploration, the creativity of the entire community, and so on. In that sense, getting all these tools, even if it doesn’t immediately change anything for like the site itself, starts to unlock a lot of things. 

Josepha [29:27]: I’m going to take a bit of your answer from there and tie it all the way back to your first answer that we had when you joined me today. And say, I think you’re absolutely right. We have a set of users in our theme authors and our plugin developers as well that we desperately need to get looking at this set of tools. I hope that what we are shipping in the first iteration of this serves as an opportunity for all of those theme authors and agency owners, plugin authors, WordPress site configurers freelancers. Like, I really hope that this puts it into a really accessible, easy-to-access space for them so that they can do those experiments based on what they know their users need the most. They are the group that has the closest access to site maintainers. And what they need compared to, for instance, me or a potential you like we have a lot of information, you and I, we do a lot of tests, we have a strong sense of what is needed at the moment, but we don’t have as a close connection that our theme and agency and plugin folks all have. And so that’s another part of why I’m so excited to get this out in the current iteration of it.

Josepha [31:04]: That was a lot of questions in a little bit of time. This is going to be officially my longest WordPress briefing. Matías, I am so glad that you were able to join me today. And I think that everyone’s going to be really, really excited to hear your answers to these questions.

Matías [31:23]: Thank you for having me.

Josepha [31:25]: All right, my friends. That brings us into our small list of big things. I’m going to skip our community highlight today just because we had a slightly longer word press briefing in our bonus iteration today. But the small list of big things. The first thing is WordCamp Central America is coming up on April 15; there is a registration link in the show notes that you can access your tickets with. I recommend that you go; we’ve got a lot of excellent speakers coming up there and a lot of good content and good training and learning for y’all. The second thing is that Matt Mullenweg and I have listening hours coming up with the community in the first week of April. I’ll add the link to register for those in the show notes as well; it’s just a few minutes for you all to stop by, check-in, see what’s going on, and share some celebrations or concerns with us. And I hope that I see you there. 

So that my friends is your small list of big things. Thank you for joining in today for the WordPress briefing. I’m your host, Josepha Haden Chomphosy. I’ll see you again in a couple of weeks!

WP Briefing: 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 [email protected], either written or as a voice recording.

Credits

References

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 [email protected].

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!

WP Briefing: My Typical Day as WordPress’s Executive Director

In this episode, Josepha Haden Chomphosy speaks to her role as the Executive Director of WordPress. Learn about the day-to-day of her role and how it supports the mission of WordPress.

Have a question you’d like answered? You can submit them to [email protected], either written or as a voice recording.

Credits

References

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!

I’ve been asked many times what the day-to-day work looks like for the Executive Director of the WordPress project. I don’t really think I’ve done a great job of answering that question. My default answer is either too broad, and I say, “I helped turn the WordPress vision into reality by supporting the community of contributors,” or way too narrow, and I start telling people what’s on my calendar. Probably no one cares about each entry on my calendar, and almost every contributor is covered by “I get things done by helping people.” So today, I invite you to join me in exploring the type of work required and the balance it takes to keep WordPress working.

First, some context on the weekly activity I see in WordPress, on average, 1,800 to 2,000 contributors a week, participate in conversations and tickets across the entire WordPress project in our entire ecosystem. There are about 20 volunteer teams that are each led by two to three team reps. Each of those teams actually has smaller groups that work on specific things; all told, it’s probably about 50 distinct teams. And probably quite a few more if you are very generous in your counting about what makes up a team for us. 

Among those teams, a minimum of about 35 meetings a week are held, plus more for working groups. That doesn’t take into account the things most people are aware of externally.  It doesn’t take into account the big quarterly or annual activity things like WordPress software releases or any of our events. When those sorts of things do happen, there’s a bit of an increase in our activity.

 I work 40 to 60 hours a week on WordPress, depending on what’s going on, to make sure that I know what’s happening now; so that I have insight into what the next three to five years will bring. All of that is in support of the WordPress community, which I define as anyone who has ever interacted with WordPress ever, regardless of whether they know it or not. In case you’re feeling a bit lost right now, we can shorthand that entire context as this is really big and really complex.

Given that giant scope, it makes sense that people wonder what the work looks like. So I’ll talk about it in three big chunks: what I focus my time on, what I focus my attention on, and what helps me balance my decisions. 

So first, what I focus my time on. I spend about a quarter of my time in meetings, mostly with current contributors, project leadership, and community members. I spend another quarter of my time in WordPress community outreach, checking in with current folks, reaching out to future WordPressers, and checking in with people that I haven’t heard from in a long time to make sure that I know what they need and if there’s anything that I can do to help. After that, I spend a bit under 15% of my time each on writing/communications work or ad hoc project work. I then spend 10% of my time reviewing proposals, editing, communication drafts for others, and determining my stances on discussions that we’re having in tickets and elsewhere. I spend all of my remaining time planning for various goals, projects, initiatives and personally working to remove blockers for our volunteer contributors. So the bulk of my time, about 50% or more, is spent in calls with people, which makes sense if you’ve ever worked with me; personal connections with the community have been the best part of my job for a long time. Since the community is what makes WordPress so great, it’s only natural that I want to stay connected. 

The second big chunk is what I focus my attention on. I pay attention to four big pillars of work in the project. The first one is the WordPress CMS itself. So that’s the core team, accessibility, design, and many, many others. The second one is the WordPress community. And that’s the training team, everybody who is working on the Learn initiative, and the actual community team as well. 

The third big pillar that I focus on is the WordPress contributor experience, which is mostly the meta team but  includes all of the teams they work with: plugins, themes, polyglots, etc. The fourth big pillar that I turn my attention to is our communication; what I am saying about the WordPress project to people outside of it and what I am helping our team reps to say about the work that we’re accomplishing for the WordPress project inside the project. In general, we have to make sure that we coordinate a big group of contributors around a common idea or a common practice as we move forward. 

Now, the way I focus both my time and attention probably isn’t quite right if you’re focused on a single feature or team. And it’s definitely not right if you aren’t spending 40 hours a week in the project; what that probably looks like for you is more like an hour in a team meeting, 30 minutes or so on clarifying conversations, and any remaining time that you are able to contribute focused on the feature that you’re actually contributing to. And so, there you have it all my time and attention. That is WordPress in a nutshell. 

This brings us to the third chunk, the balance part. You might be wondering, how do I make sure I am fair and balanced in decisions that I have to make. That is something that I think about all the time, and I take very seriously. It’s hard to make decisions that might affect 2,000 people. It’s even harder when those decisions might affect 40% of the web. I know that I don’t have all the answers. And I’m fortunate enough to have 50 or 60 people in the community who offer me advice and guidance every single week. I’m in constant contact with the project lead, of course, but I also prioritize messages and concerns raised from team reps. And I always strive to understand before I try to problem solve. I don’t always get it right, but I do always work to get better. And that is the day-to-day work of a WordPress executive director.

That brings us to our community highlight. I tweeted out into the community asking for excellent examples of Freelancer success stories, and today I’m going to share a story from Arūnas Liuiza. Their story goes like this: 

“For almost a decade, freelance WordPress gigs allowed me to support myself and my family and keep my full-time teaching position at the local college, which was paying peanuts but was an awesome, meaningful, and fulfilling. I am sincerely grateful for that.”

That brings us to our final segment of this brief podcast. The small list of big things to keep an eye out for in the next two weeks in WordPress. I only have two things this week. The first one is daylight saving time. It is that time of year where daylight saving time starts or stops at various parts in the globe. If you are a team rep here at WordPress, don’t forget to talk to your teams in your meetings in the next few weeks to decide what you’re going to do. You can move your team meeting if you want, and you can keep it where it is and see what new voices show up when it moves around for various people. Either way, make sure that you chat it out with your team and make sure that everybody understands what is and isn’t moving on your calendar. That will also be relevant to any of our brand new work-from-home folks in the middle of this global pandemic. 

The second thing to share is that there is a major release of WordPress coming up that’s going to happen on March 9th. It’s WordPress 5.7; it’s going to be a good release. We’ve been working on it since December or maybe a little bit earlier. So keep an eye out for announcements about that here on wordpress.org/news, or if you want to follow more about the developer details and the process details you can head on over to wordpress.org/core. 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!