INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

BRAD: Welcome to Episode 49. Today, Pippin and I welcome Drew Jaynes, who led the release of WordPress 4.2 earlier this year. Drew, welcome to the show.

DREW: Thanks for having me.

PIPPIN: It’s awesome to have you on.

BRAD: Yeah. Before we dig into the challenges of leading the 4.2 release, I was thinking I’d like to take a few minutes to raise a glass to Alex King, who we lost to cancer last week. Alex was a huge influence in the WordPress community and a very successful entrepreneur as well. But, rather than list his achievements, I thought we could just share our stories of Alex. Pippin, how did you know Alex?

PIPPIN: I actually had the opportunity to meet him a couple of times, several times just kind of in passing at different WordCamps, and had always been impressed with him. I had been familiar with some of his work or a lot of his work, really. He was very, very prevalent throughout the WordPress community and outside.

But, I also had the opportunity to sit down and have dinner with him once, I think at either PressNomics or WordCamp Phoenix. It was one of those times when you — have you ever been in a place where you sit down or are in a close space with somebody who you’ve looked up to for years and years and years? It’s a really cool experience, and so I got to sit down and have dinner with Alex. I just remember being so incredibly humbled by how friendly, conversational he was.

Here’s this guy, Alex, who everyone in the WordPress world knows, a lot of people outside, he’s had amazing influence throughout the development world. Here he was just a very casual, nice conversation, and I remember being extremely humbled and honored that he actually knew me by name. I felt like a nobody, and here’s Alex. To me, that was a really great symbol for who Alex was that he was always so friendly to everybody. He was an awesome person.

BRAD: Yeah. I remember someone saying to me something like, “Hey, he’s just a geek. He’s just like us. He’s totally geeking out on dev stuff with me.”

PIPPIN: Yeah, absolutely.

BRAD: But he’s running this big profile agency, dev agency too. Yeah, I think that was an interesting comment that someone made. I was like, yeah, I guess I never thought of it that way. I guess some people thought that Alex was more of a businessperson, right? I guess he was. He was both.

PIPPIN: He clearly ran a very successful business that’s still around today, Crowd Favorite. I think he was the original founder of that.

BRAD: Yes, that’s right.

PIPPIN: But, yeah, he was a geek.

BRAD: Yeah.

PIPPIN: Drew, did you have an opportunity to spend time with him ever?

DREW: Well, you know it’s funny you mentioned Crowd Favorite because I always knew Alex as the incredibly intimidating owner of Crowd Favorite, which here is the local shop, right?

PIPPIN: Right.

DREW: I met him a couple years ago, finally, and he wasn’t intimidating at all, but it seemed so intimidating to work for Alex’s team. You know he was the originator of WordCamps in Denver. He and Crowd Favorite ran the first two WordCamps in 2009 and 2010.

We had him on as a moderator for this really, really successful UX panel in 2013, and I had an opportunity to bond with him then. Honestly, he told us the worst thing about panels is that they have terrible moderators. We said, well, that’s why we picked you.

PIPPIN: Nice.

DREW: He was a great guy, and he was immensely talented.

PIPPIN: I just read — Matt Mullenweg posted a really nice “Remembering Alex King” post. Something that I had never known was that Alex had actually been around in the WordPress world since before WordPress. He started on B2, and that was news to me. I knew that Alex had been around for a long time, but he was literally here from the beginning. It’s amazing.

BRAD: Yeah, that’s a really good post that Matt made, actually, about Alex.

PIPPIN: Yeah, it was awesome.

BRAD: I thought it was really well done. Yeah, we’ll link that up in the show notes so everyone can take a look.

PIPPIN: There are two other really nice posts for Alex that you should check out. We’ll link them as well. That was one that Brian Krogsgard wrote up on Post Status and then another one from Jeff Rowe at the WPTavern. We’ll link them all in the show notes.

BRAD: Cool.

PIPPIN: Yeah.

BRAD: I just want to say that I met Alex for the first time at PressNomics, actually. He was very enthusiastic about the WP App Store, and he was emailing with me back and forth before I even met him in person and kind of helping me along a little bit. That was really cool. I was super humbled by that. I was like, what? Alex is reaching out to me? I’m nobody.

PIPPIN: Yeah.

BRAD: We played a round of golf at PressNomics as well, and we both shared kind of a passion for sports, and golf in particular. That was pretty special to be able to do that.

PIPPIN: Yeah, he definitely left his mark on the community.

BRAD: Yeah.

PIPPIN: Alex was awesome.

BRAD: Yep, so he will be missed for sure.

PIPPIN: Yep. Drew, let’s dive into you for a little bit. We want to talk about some of your experiences leading WordPress 4.2 and some more generic kind of open topics around the aspects of leading development for large community-driven projects such as WordPress. Before we do that, though, I believe your technical title is Platform Engineer at 10up.

DREW: That’s right.

PIPPIN: What does that mean?

DREW: I’m actually the originator of this title, and this actually hasn’t been announced yet.

PIPPIN: Ahh! Whoops!

DREW: Well, yeah. Whatever. It essentially means that I am solely focused on one platform that 10up relies on, which in this case, of course, is WordPress. The standard titles at 10up are Web Engineer, Senior Web Engineer, whatever. As I moved from them donating basically half of my time to now 100% of my time, we had to come up with something better than Web Engineer.

PIPPIN: That’s so cool.

BRAD: Platform Engineer, that title hasn’t been announced? Is that what you said?

DREW: That’s right.

BRAD: But you’ve updated your Twitter profile already.

DREW: I have. Yeah. Let’s just say it should have been announced already.

PIPPIN: Okay.

BRAD: I see.

DREW: It should be soon.

PIPPIN: There are a few people listening to this podcast.

DREW: Yeah.

PIPPIN: We’ll be fine.

BRAD: You’re 100% on WordPress core, right?

DREW: WordPress core and community because it’s not just core, but yeah.

BRAD: Right.

PIPPIN: That’s awesome. In this case, does community mean things like WordPress.org itself with the meta team?

DREW: Yeah.

PIPPIN: Basically anything involved with the WordPress project?

DREW: Yeah. I’m pretty active on three or four different teams: core, docs, meta. Then there are a whole bunch of projects that I work on that are hybrids of all three of those things, like the developer hub for instance.

PIPPIN: Very cool.

BRAD: What’s that? What’s a developer hub?

DREW: Developer hub is part of the docs roadmap that we formulated a couple years ago in Cincinnati. That’s the code reference. There’s a dashicons reference. There are the theme and plugin developer handbooks.

PIPPIN: Right. It’s developer.wordpress.org, right?

DREW: Right, the developer….

PIPPIN: The new version of the codex.

BRAD: Ahh, I see. I see.

DREW: Yeah.

BRAD: That’s separate. Right, it’s a new version of the codex. It’s separate from the make blog stuff.

DREW: Yeah.

BRAD: Right.

DREW: It’s separate from the make network. It’s essentially, the different between the codex and the developer hub or the developer reference is, the codex is community documentation and the developer reference is official documentation.

BRAD: Ahh, okay.

PIPPIN: Am I right that at some point the plan is to actually remove the codex completely?

DREW: That’s right.

PIPPIN: Cool.

DREW: Eventually. That’s not going to be any time soon.

PIPPIN: That’s a long process, for sure.

DREW: Yeah.

PIPPIN: I am impressed with how far the developer.wordpress.org site has come since it first launched not even that long ago. Is it even a year old at this point?

DREW: Well, it’s actually been up for a while, but I think Matt announced it during the State of the Word at WordCamp San Francisco last year.

PIPPIN: Okay.

DREW: But it was up for probably six months before he announced it.

PIPPIN: Sure. It’s definitely progressing very fast, it seems.

DREW: Absolutely. As part of the work that I do on core as the docs committer, the developer reference is displayed from parsed documentation that comes from the source, and that’s why we had to have sort of somebody managing and maintaining the source documentation because it goes directly into the code reference.

PIPPIN: Got it. That’s very cool. Let’s move on and talk about WordPress 4.2, which is the release that you led back in January of this year, I believe, 2015.

DREW: Yeah, I think it was January to April.

PIPPIN: You led that release, and this was a big release that had a couple of significant improvements. Customizer theme switching was one, ajax plugin updates. I believe this was the first part of the shared term splitting timeline and was also the big emoji release, emoji/utf8mb4, and also Press This.

DREW: Right.

PIPPIN: What does leading a release really entail? Obviously development happens because new features are built, bugs are fixed. But, as a release lead, you’re not doing all that development. What does a release lead really do? Maybe tell us a little bit about that.

DREW: I think a good sort of parallel is if anyone has ever organized a WordCamp or organized an event. I think that’s maybe a good parallel to what a release lead does. You’re essentially wrangling resources. You’re a project manager.

BRAD: Right. You’re herding cats. Is that another metaphor?

DREW: Sometimes, sure. I think it’s definitely managing your resources. And, in a project where everyone is a volunteer, that can be a challenge. It helps to have a good base of knowledge in terms of how previous releases worked, things that maybe didn’t work in previous releases that you want to try and improve on. But it’s largely project management. You’re working; you’re keeping track of so many different details that you can’t even imagine.

BRAD: Right. How much development do you do personally? Do you get into the code during that time, or do you keep out of it?

DREW: You can. It depends on what your focuses are going to be during the release. Scott Taylor has been doing — he’s beating all of us in terms of development in 4.4, so it’s not like you can’t be involved in development.

PIPPIN: He’s the release lead for 4.4, isn’t he?

DREW: That’s right, and he has, I think, almost 400 commits in this release.

PIPPIN: Wow!

BRAD: Yeah.

DREW: It’s pretty ridiculous.

PIPPIN: Speaking of commits, I believe, Wednesday, you had just passed your 1,000th commit to WordPress core.

DREW: Yes, it was.

PIPPIN: Congratulations.

DREW: Thank you.

PIPPIN: That’s awesome.

BRAD: The millennium.

DREW: The really, really cool thing about that, I think, is that probably 950 of those were docs commits.

PIPPIN: Which is really, really awesome because the inline and developer docs are just not something that a lot of projects see, maybe people have varying levels of appreciation for. But I will tell you, personally, I absolutely love the docs, the work that you put into internal docs in WordPress core.

DREW: Yeah. I think at last count I added or fixed something like 35,000 lines of documentation in core. In 1,000 commits, that’s what you get, a 1:3 ratio.

BRAD: Just to be clear, we’re talking mainly about doc block comments, like above functions and that kind of thing, right?

DREW: That’s right.

BRAD: Okay. Cool. You’ve been going through and fixing a bunch of inconsistencies, I guess, and adding probably new documentation where it’s missing.

DREW: Right. Initially, the reason I was originally granted guest committer status in the first place was because I was leading the effort to document all the hooks in core.

BRAD: Right.

DREW: That spanned the 3.7, 3.8, and 3.9 releases. When that was finished, I just kept going.

BRAD: Right. I’ve noticed those hook comments, by the way, and they’re spectacular. It’s so nice to go to a hook. You find it in the code, and then there’s actually a doc block in there that actually tells you about it.

DREW: One thing a lot of people don’t know is that we actually developed an inline documentation standard because there wasn’t one for core before that. We did that because we had to have a standard way to document hooks. But then what happened was, when we were done with hooks, then all of a sudden we realized that all the rest of our documentation was sort of fragmented in terms of style, correctness, and completeness, so that’s sort of where I lept onto it and started to try to get the other documentation in line.

BRAD: Right. One thing I’d like to ask you about, well, first of all, correct me if I’m wrong. Didn’t some things have to get rolled back before the 4.2 release specifically around updates, like in place?

DREW: Yeah, shiny updates.

BRAD: Yeah, yeah. What did you call it, shiny updates?

DREW: Yeah, that was the name that we used was shiny updates.

BRAD: Right, right. What happened there exactly?

DREW: Well, I guess I should rephrase that. It’s not the shiny updates. It was shiny installs is what got reverted.

PIPPIN: Shiny updates stayed.

DREW: Right, shiny updates are essentially the ability to update plugins in line from the, like, plugin list table.

PIPPIN: Which is a wonderful, wonderful feature.

DREW: Yes.

PIPPIN: Every time I use it, I am so happy. It just makes me smile.

DREW: Exactly, and it was easily my favorite feature.

BRAD: Right, so that’s the no page reload. You hit update, and it just updates the plugin in place.

DREW: That’s right.

BRAD: It doesn’t reload the page. Yeah, right.

DREW: Right.

BRAD: That’s nice.

DREW: But the part that got reverted was that actually was also possible for installing plugins from, like, the plugin install screen. You could just click the “install now” button and it would just install it.

BRAD: Right.

DREW: There was no redirection to another page and then activate. That was actually why it got reverted was because we had no good handle on sort of what the activation procedure should be.

PIPPIN: Right.

DREW: Should we auto activate it? What happens if plugins redirect to some other page after activation?

PIPPIN: Which is pretty common.

BRAD: Yeah.

DREW: Exactly, so that’s why we kind of rolled it back and said, well, maybe we should take a little more time with that part of it.

PIPPIN: I wonder. I think I’d love to see it revisited. I’m not sure if there’s a roadmap for it, but one way that I can see that possibly working is you click install, it goes ahead and installs it, and then gives you the prompt of, okay, do you want to continue browsing or–

DREW: Well, Konstantine Obenland, actually, the 4.3 release lead, and I had talked a little bit about maybe trying to tackle that in 4.4. I don’t think it’s obviously going to happen now, but Mel Choyce from Automattic had this really great idea–I believe it was her idea–that it was during 4.2 to use the plugin card UI. Right? So you’d click “install” and then maybe the card flips over and you get the information about the plugin installation. Then you could click “install” or “activate” from there, for instance.

BRAD: I like that, yeah.

PIPPIN: That’s cool.

DREW: In place. We talked about it a lot, and I think it was a really popular idea. It’s just somebody’s got to do it.

PIPPIN: Right.

BRAD: I guess the flow wouldn’t change then because you’d do both actions, still. You would install, and then you would activate it, like two separate clicks.

DREW: Right, but the difference is it wouldn’t take you to a new screen.

BRAD: Yeah.

DREW: It would just do it in sort of a container in the screen. I think that would be fantastic.

BRAD: Right.

PIPPIN: I want to dive into a comment that you just made. You said somebody just has to do it. I think that is something that anybody who has led development of community-built software experiencing at some point. With open source software, whether it’s WordPress, a plugin for WordPress, or a totally different software, be it Drupal, Joomla, or any open source software, there are people that lead development. Then there are also a lot of volunteers that volunteer their time to work on something.

What do you think are some of the challenges of trying to lead the development of a community-built software, especially one that’s the size of WordPress? Just being a lead, whether it’s a release lead or simply being a leader of the project in that you spend a lot of time on the project, that doesn’t mean that you can still build every single feature. A lot of times you ask to get somebody to volunteer to build that. I’d love to dive in and kind of get an open discussion going about some of the challenges and advantages and good and bad of community–

DREW: That’s the major elephant in the room, basically, is working with volunteers, right?

PIPPIN: Right. Hey, I would love to build this… six months later.

DREW: Exactly. Yeah, yeah. I think a big part of that is, well, I guess I should start with there’s a nuance to that because everyone is a volunteer. Even I’m a volunteer, but the difference is that 10up is paying me to be a volunteer, right? There are some people who are being paid to volunteer because that volunteer distinction is very important in WordPress.

Some people are being paid to volunteer. In those cases, they are more driven to work on larger features. But then you have other people like Pippin Williamson here who worked on some of the early password generation stuff that shipped with 4.3. Let’s probably not go there. Which, by the way, the back-story there is Pippin and I worked on that. Then they actually basically redid all of our efforts because they had no idea that we had worked on it.

BRAD: Oh, no!

PIPPIN: They discovered that both of them had been done almost exactly the same, but just slightly different.

DREW: Yeah.

PIPPIN: But one got completely stowed away.

DREW: In that case, we had too many volunteers, I guess. But volunteers is the big one. I think it’s working with people who don’t necessarily have to do what they say they’re going to do, so you pretty much just hope that they will.

When you get into the mindset of, well, somebody just needs to do it, that would be somebody just needs to step up and take charge even if they’re not leading development, because somebody leading an action item in core doesn’t necessarily have to be a developer. They just have to be able to produce results, right? In a way, you have almost miniature release leads, action item leads.

I don’t know. I think it really comes down to figuring out to wrangle volunteers.

PIPPIN: Wrangling volunteers to actually get the work done is a big one. What about managing things like community expectations? We see users, users of software who are not developers, who are not involved with any of the development or the planning process are one of the best voices for figuring out what the needs of a project are.

DREW: Sure.

PIPPIN: We need this feature, this feature is buggy, this feature is just hard to use, or whatever.

DREW: Right.

PIPPIN: How do we manage those kinds of expectations? I think we all know that if you have somebody ask for something, you can’t just let it sit there and be silent. You have to have an open flow of communication with users. Well, when you have a software that’s used by millions and millions and millions of people, who do you do that? Insights?

DREW: It’s a tough balance. It really is. When decisions are made, like for instance in WordPress core, they try to weigh everything against what’s known as the 80/20 rule. That is, whatever decision we make should benefit 80% of the user base.

The lead developers are pretty good at gauging what that is, and a pretty good track record with guessing, educated guessing, really, what 80% of the perceived users need. I think there is a delicate balance, though, because you don’t want to alienate your user base by making decisions for them without their inputs. I think we’re seeing a lot of improvements in that area now. We’re starting to post proposals and roadmaps on the core development blog.

We’ve always sort of done that, but now we’re making it more of a prevalent part of the process. You’re seeing now, I think, two proposals from the short code roadmap, for instance. That affects a lot of people, tons of plugin authors, tons of users.

We want to make sure we get that right, so now, more than ever, I think we’re open sourcing the decision making, I guess is a better way of putting it. It’s not that it wasn’t open sourced before. It’s just that there was kind of a barrier to entry.

PIPPIN: Sure. Trying to make it more visible and easily accessible.

DREW: Absolutely.

PIPPIN: Yeah. I think, while my management of a project is significantly smaller scale than, say, WordPress, we see that even in things like Easy Digital Downloads where we’re talking about a few thousand websites as opposed to a lot of millions. But, we find that those exact same things apply in terms of just trying to be open. That 80/20 rule is golden.

I think any open source developer, or not even open source. Any developer who is building a project should try and use that 80/20 rule. At least a good way to kind of get a basic judgment on whether or not something should be built or fixed or changed. You could have two very vocal users request a feature or a change over and over and over again.

DREW: Sure.

PIPPIN: But that doesn’t mean that it benefits everybody.

DREW: Well, yeah, and it really becomes this idea that you have to sort of propose the problem before you can propose the solution. WordPress has been very, very successful at putting the users first. In a lot of cases, that’s extremely frustrating to developers because we put the users first in almost every decision. But then again, we also have an amazing market share in the industry, so we’re doing something right.

PIPPIN: I don’t think those two are unrelated.

DREW: Yeah.

BRAD: I noticed, like during 4.2, you were doing Friday bug scrubs. Was that something new that you implemented for that release, or was it previous? Was it going on previously?

DREW: It was absolutely going on previously. I think the difference is that every release does it differently. Usually, as you get closer and closer to the end of the release, you’re doing more frequent bug scrubs, right? The difference is, I think, that in previous releases they had been doing maybe a Friday bug scrub once a week or sometimes it’s sporadic, like they’ll do it right after the dev chat on Wednesday.

BRAD: We should probably describe what a bug scrub is.

DREW: Right, so a bug scrub, in the context of WordPress core, would be we have reports of listing out all the bugs that are flagged for the current milestone. Typically, what that means is we pick a chunk of that report to go through together as a group in chat and try to solve or get them moving because that’s the endless battle during release is to keep your ticket count as low as possible. Scott Taylor has been really on top of it in 4.4 where he’s really trying to keep it below 200, which is….

BRAD: Single-handedly.

DREW: Well, I mean not single-handedly, but he’s definitely — yeah. The bug scrub thing is mostly to try to keep tickets moving because they’ll stagnate if you don’t sort of nudge people along. A lot of that, honestly, is people upload batches and walk away, and they don’t recognize that they need to participate in their tickets in order to keep them moving.

PIPPIN: Right. If you want a ticket to be resolved, you need to participate. Any amount of time that you put into it is always appreciated, but that doesn’t mean that it’s going to be put in.

BRAD: I wonder if some of the kind of leaders in the core community should be pushier because, like right now, I’ve noticed. I get notifications when people are posting a ticket that I submitted a patch to or something, but no one really says, “Brad, get in on this.” You know what I mean? Like a nudge or something.

DREW: It’s definitely easier to ask than it is to tell.

BRAD: Yeah, right.

DREW: The last couple years, we’ve really started to get into this habit of, you know, everyone needs to be welcoming no matter what. No matter who you are, no matter what your skill level is, you’re welcome on Trac. We will walk you through it if you don’t know how to do it.

I think it’s a lot better to ask. Wonder Boy Music, can you please take a look at this? Versus, I think there’s a ticket. I can’t remember what the number is. I think it’s 17187 or something. It’s for this recursion ticket that you’ve been pestering me to review for a couple of weeks now. We can’t just say, “Nacin, do this.”

PIPPIN: He doesn’t have anything to keep him busy.

DREW: Yeah, he doesn’t have anything to keep him busy.

PIPPIN: It’s not like he’s working at the White House or anything.

DREW: Right. Honestly, it’s easier to ask, and it’s better to ask because it’s a push/pull relationship in WordPress development.

BRAD: Do we pose that question often enough, or do we just kind of stay silent and hope that they come back? Do you know what I mean?

DREW: In general life or in WordPress development?

BRAD: In WordPress development, yeah, in the context of WordPress development.

DREW: I think we’re getting better. There’s been this sort of number floating around: 3,000 tickets. I don’t know if you’ve heard that. We’re trying to get below 3,000 tickets.

The problem we have is, in any given release, we’re fielding new tickets coming in. Some of them are related to the release, some of them are just random things that people are asking for, and we have to continually try to keep the ticket count down. The way you do that is by commenting on tickets and finding duplicates and triaging, right? It plays into your question.

It’s like if somebody just dumps a ticket in Trac and they don’t participate, then you have to kind of figure out, like, well, do I need to nudge this person along, or is this something that’s really kind of plugin material? Do we have time and resources to work on this? Maybe it’s maybe later. Honestly, keeping on top of the never-ending fire hose of tickets is a real challenge because we’re keeping up with new tickets coming in and trying to get rid of tickets that have been stagnating in Trac for years, in some cases.

BRAD: Yeah. I can’t imagine trying to do that at all. I just look at a very tiny, just tiny little corner, little slice of the tickets. I find that’s hard to keep on top of half the time.

PIPPIN: Right. On a small scale, or not super small scale, but much smaller than the fire hose scale, it’s kind of like trying to manage customer support requests while also trying to fix the things that cause those requests, at the same time.

DREW: Exactly.

PIPPIN: Keeping on top of that is challenging. Then the fire hose on WordPress core is just that times 5,000.

DREW: Yeah, and we have a good crew of people that sort of do a lot of triage work. Chris–I don’t know what his actual name is–Chriscct7.

PIPPIN: Chris Christoff.

DREW: Yeah, Chris Christoff has been doing amazing work triaging tickets the last couple months.

PIPPIN: He’s a machine.

DREW: He is. Honestly, to go back to your original question, Brad, I think we sort of employ a strategy with tickets. If somebody reports something, walks away, we ask for feedback and, after some reasonable grace period they don’t come back, we’re just going to close the ticket because we don’t want it just sitting there. You kind of generally have to nudge people along. But, some people are better at it than others, so some people don’t necessarily need that nudging. They just have to do it. Then we circle back to: They just have to do it.

BRAD: Right. The fire hose is really interesting. I’ll share a little bit of how we feel about it. As a company, we’ve been doing the core contributor day. Every member of the team spends an entire day doing core contribution.

What we found after doing it for a few months is, we spent half that day just trying to catch up on tickets and find a ticket to work on that made sense. We spent a lot of time just looking at tickets and just participating in the tickets, and not actually coding, which most of us felt was where the main value that we could bring to the project would be. And so, we were a little discouraged by it, to be honest, which is one of the reasons we moved over to GlotPress because the fire hose there is just a trickle, comparatively, and we felt we could make a bigger dent over there. I just wanted to share that with you guys.

PIPPIN: I think the value of triaging a fire hose is one of those that is not necessarily underappreciated, but people a lot of times don’t realize how valuable it is just triaging those tickets.

DREW: Actually, that’s what I was going to mention. I think a lot of people get discouraged because their tickets aren’t seeing a lot of movement. Honestly, now we’re in a position where if you categorize your ticket properly, someone will see it. Someone will read it. Someone will probably interact with it fairly quickly because we have component maintainers now, right, where people follow and people sort of shepherd specific tickets in different components.

If you can try to get the component pretty close or the focus pretty close when you create the initial ticket, it’s pretty likely that the component maintainer will get back to you pretty fast, which is night and day compared to what it used to be like. There were basically all people shepherding all tickets, in a way, whereas now you sort of have people taking a lead within their own components, which is really fantastic for Trac gardening.

PIPPIN: I found that, for me, as an outside contributor that, over the last year, I’ve been trying to get a little bit more actively involved in a particular area. I found that just subscribing to one component, like I subscribed to the plugins and the users components, I think. Just doing that alone made it much, much easier, for me at least, to give back some of that time and to manage it, and get a better understanding and idea of what goes on there.

DREW: That’s a good approach because the problem is people come into core and they get overwhelmed, right?

PIPPIN: Right.

DREW: There are so many things to keep track of. In my case, it’s my job to keep track of all those things. But, it’s not everyone’s. You’re right, it’s absolutely the best approach to maybe pick a couple of components that interest you and stick with those.

PIPPIN: I think it also goes to show the importance of making sure that a ticket does get put into the right component because that way those people that do focus in a particular component, they’re going to see it.

DREW: Sure.

PIPPIN: I want to ask about something that just happened pretty recently, and that’s language packs. Drew, I would love to hear your thoughts on language packs for plugins.

DREW: Uh, well–

PIPPIN: Real quick, actually, for anybody who is listening that doesn’t know, can you explain what language packs for plugins are?

DREW: The basic gist is that WordPress.org is adding support to the translation infrastructure they already have in place for translating things like WordPress core to making it possible to translate all plugins in the repository and all themes in the repository. There are various rules that go along with that, like how to make that work that your text domains have to match your plugin, your theme, or whatever.

PIPPIN: Yeah.

DREW: The basic thing is, the infrastructure of language packs is awesome. The idea is awesome that any plugin or any theme could be translated. I think it’s going not be a little bit of a rocky start because, theoretically, plugin developers who are already localizing their strings already have translators who could then go and contribute on Rosetta, GlotPress, or whatever, as part of the Polyglots team. They could go directly contribute to the translations of your plugin, but they have to do it through this other interface now or something.

But I think it’s going to be a little bit of a rocky start, and that’s my personal opinion, because I think right now what we have is the core translators who maybe feel like they’re getting the entire plugin repository and theme repositories dumped on them. I can’t confirm that, but I think my first question would be, “Did I sign up for this?”

PIPPIN: Right.

DREW: But I think there are a ton of plugins that do have a translator. I’m assuming you guys have translators for EDD.

PIPPIN: We do. EDD, the last we counted, is partially to 100% translated into 120 languages.

DREW: Wow!

PIPPIN: I didn’t realize it was that many until the other day when we counted them, and we had to double-count because we thought that was too high. We’re like no way that’s right. Turns out it is because we have a guy who is just amazing that wrangles translators. But, you mentioned something a little bit ago about it being a little bit of a rocky road, possibly.

DREW: I might get in trouble with Dominik Schilling for saying that, but that’s my personal opinion. I think it could be a little bit of a rocky start, but–

PIPPIN: I want to tell you about kind of one of the reasons that it’s a rocky road for us. Now, let me preface this by saying I am very excited about being able to translate plugins on WordPress.org. I think it’s a really, really cool infrastructure that, while it may take a little while to pick up speed, I think, in the end, will be awesome. The reason that it was a little rough for us, one, we had to change a text domain.

DREW: Yeah.

PIPPIN: We thought it was actually going to be a lot more painful than it was. We successfully changed it. We had to change 318 files and over 3,400 text strings, and so far we haven’t had a single ticket about anything breaking. Crossing fingers.

DREW: That’s awesome.

PIPPIN: Anyway, Bernard — I’m always going to get in trouble with him because I never know how to actually pronounce his name, but he goes by FXB. He is one of the French maintainers for WordPress.org and does a lot of translations. He managed the EDD translations for us on TransFX, and he was amazing at wrangling translators and getting people together to … languages, and that’s why we have 120 different languages for EDD.

The rocky road for us now is we have this big project that he has been working on and getting all these translators involved with. Now, suddenly it’s split. There’s TransFX where you can still translate it, and now there’s WordPress.org. Where should you contribute translations to?

DREW: That’s the thing. It seems to me that it’s opt-in, right? If you opt in, you essentially opt out by not matching their text domain requirements.

PIPPIN: Or by just not doing it.

DREW: Right. The thing is, the real benefit you get out of language packs is that you no longer have to ship all of those languages with your plugin because it comes from WordPress.org. It comes on an as-needed basis, right?

PIPPIN: Right.

DREW: That’s the really cool part. You say you have 120 languages, but who speaks 120 languages?

PIPPIN: Right.

DREW: Their users just may have two or three language….

PIPPIN: Why should somebody who is speaking Basque, why should they have English, Chinese, German, Spanish, and all these other languages installed with them? It’s just pointless.

DREW: Yeah. I think it’s going to cut the download size just slightly because the … files are definitely — they take up a little space.

PIPPIN: Right. The caveat, though, is that the only languages that get shipped are those that have 100% translation.

DREW: Yep.

PIPPIN: Which is tough.

BRAD: Oh, wow.

DREW: That’s the rule … and that’s just how it works.

PIPPIN: Right. Basically, if you have translation files that are not 100%, you ship them with your plugin. As soon as they reach 100%, you take them out of your plugin. Then they get shipped via the language packs.

DREW: Right. Yeah. They probably just want to make sure they’re shipping complete translations.

PIPPIN: Right. There’s good and bad sides to it.

DREW: It’s a really cool improvement. It’s been coming for a really long time. We’ve been shipping translations for core for a really long time, but sort of moving that into the plugin and theme space, I think it’s going to be really interesting. They’ll work out the problems.

PIPPIN: Yeah.

DREW: If they find that the 100% rule isn’t really feasible, then they might have to relax that, but we’ll see.

PIPPIN: One of the things that I’m excited for is that I think it opens up the world of translation a lot better.

DREW: Sure.

PIPPIN: Before, translating a plugin has always been different for every plugin, number one, because not all plugins can be translated. Everyone manages translations in a different way, so it’s opening up a general process for translating plugins across the board and making it accessible for anyone.

DREW: Absolutely.

PIPPIN: That excites me a lot. Another benefit of it is you can contribute a translation and, if you get it approved, it can still be hosted on WordPress.org, and you can download the translation file and use it in a plugin. It doesn’t have to be 100%.

DREW: Right.

PIPPIN: You can still utilize that system for translated plugins. Now it’s easy. You go to translate.wordpress.org. You pick your language, and then you go find a plugin. If somebody is looking to get involved with contributing to the WordPress project, whether it’s core, plugins, themes, meta, it turns out you can also translate the iOS and the Android apps through this, which I didn’t know until now. Somebody who wants to get involved can do that much more easily now, and that excites me.

DREW: Well, and you know, it’s funny you speak of the people who can get involved. The thing is, there’s a validation process in approving translations. Literally, if you speak another language, you can help translate. That’s insane, if you think about it. Anyone who speaks any language can help.

PIPPIN: Yeah. That’s so cool.

DREW: That’s crazy. In my opinion, it’s like the rest API coming to core is the same as language packs coming to plugins, in a way. The impact. I think it’s going to have an amazing impact on people’s ability to feel like they have something to contribute.

PIPPIN: Absolutely.

BRAD: Yeah. I’m looking forward to when the .org team gamifies the translation system, so you get badges for more translations.

PIPPIN: Actually, I thought there was a badge already for translations. Is there not?

BRAD: Oh, really?

DREW: I actually think they had two profile badges, and I think now they’re going back to one. Yeah, I would….

PIPPIN: Dang it! I wish I spoke another language.

DREW: Ask Sam Sidler about that. Sam Sidler is your man, talk about gamifying that.

BRAD: Nice. I have been talking Sam, actually, about the GlotPress plugin. We’re working together on moving GlotPress to a plugin rather than a standalone install. Yeah.

PIPPIN: I think I just saw Sam post an update to the Make blogs about that.

BRAD: He did. Yeah.

PIPPIN: Yeah, that’s cool.

BRAD: Yeah, so that’ll be nice.

PIPPIN: For anybody that doesn’t know, translate.wordpress.org is powered by GlotPress.

DREW: Which is not currently — well, it’s BackPress space currently, right?

PIPPIN: Right. It’s not GlotPress out of the box, but it is based on that.

DREW: Right, and the plan for them is they’re going to roll it into a WordPress pluigin.

PIPPIN: Right.

DREW: Or, a part of the team is going to do that. Yeah.

BRAD: That’s the plan.

DREW: It’s really exciting. I think it’s going to be awesome.

PIPPIN: We’ve got a little bit of time left. Drew, there is one more subject I’d like to get your thoughts on, and there are kind of two aspects to it. Number one, I am very excited about term meta coming in WordPress 4.4. I think that is very exciting. It’s introducing a new table for term meta, and not really a new metadata API, but a new set of helper functions for adding metadata to taxonomy terms. This goes along with the next part of my question is: What are your thoughts on plugins using things like custom tables?

DREW: Well, you know very well what my take is on that because we talked about it at WordCamp Capetown a couple weeks ago. All right, so first of all, term meta – very exciting. That was a long time coming, right? I think even now the switch hasn’t flipped for some people. It’s sort of like remember when custom taxonomies and custom post types came out. People were like, well, why would I ever need another post type? I think, when the switch flips, it’s really going to be cool because we’re really, really going to see a lot of cool stuff.

In terms of separate tables, I think, actually, Pippin, I’m going to cite you from one of your earlier Apply Filters episodes. It was something along the lines of I think that it’s perfectly fine to have a separate table if you have a large, sort of diverse data set that you need to access, and it’s not really something that fits within the scope of a current, like a post object.

Tons of people try to flex post objects to do all kinds of things because they want to use existing WordPress tables when I think, in a lot of cases, it would be a lot more efficient to use a separate table. That’s subjective. The only time I would ever really consider using a separate table is if it was something where I needed to directly impact performance, such as indexing very specific columns, but also where I had a large, diverse data set that really didn’t fit within the confines of the current WordPress object.

PIPPIN: One little follow-up question for you. I’m very excited for term meta, and I know you are as well. What are some basic examples? I actually saw a conversation on Twitter. During this episode, I was watching where Jeff Rowe from WPTavern asks, “What does term meta really mean? How can we use it?” Why don’t you give us and the listeners a few examples of what term meta….

DREW: I think we spit out a couple examples in that thread. I think we spit out a couple like you could set featured images for categories. I can’t remember what some of the other ones were, but you could set. It’s basically like, imagine posts with no post meta, right? That’s what terms were before term meta.

PIPPIN: Mm-hmm.

DREW: You can add any kind of arbitrary, extraneous information to a term now, whereas before you couldn’t. Another good example is, like, let’s say you’re running a membership site, right? You could assign permissions to specific tags, or you could design on sources to specific tags, right?

PIPPIN: To expand on your example there on permissions, this is something I did three or four years ago. Somebody wanted to password protect every post that was in a particular category, and so, using a piece of term meta, set a password for that post. That had to all be done custom back then.

DREW: Right.

PIPPIN: But, now you could very easily just say add a piece of term meta that says this is the password. If the post is loaded that’s in this category, require a password to view it.

DREW: Yeah. Honestly, the sky is the limit, and I think it’s going to be just like I said, just like what happened when post types came out. I think Justin Tadlock was instrumental in sort of getting that switch flipped in people’s minds. I think he did a book catalog or something, example around 3.0 or 3.1. That really, I think, turned a lot of people onto using post types. I think it would be nice to see somebody really push something out there using term meta to really get people’s minds turning because there’s going to be some really cool stuff that comes out of this.

BRAD: I like your example with the featured image for a category. I think that’s what you said.

DREW: Yeah.

BRAD: I can picture that category page and, at the top of that category page, there’d be an image and maybe a description about the category as well, right?

DREW: Right. Up until now, all you had was a title, a slug, and a description field for terms.

BRAD: Right.

DREW: Now you have….

PIPPIN: Was it Justin Tadlock that wrote the taxonomy images plugin?

DREW: I’m not sure. I wouldn’t doubt it.

PIPPIN: There’s a plugin written a long time ago called taxonomy images, so that was basically exactly that. It allowed you to assign an image to a taxonomy. No, sorry. It wasn’t Justin Tadlock. It was Michael Fields that wrote it, and it was basically for that exact same purpose, but this is using a completely custom system.

Justin Tadlock did just show an example on Twitter in response to Jeff Rowe’s question where, what if you could have– Okay, it’s very common for news blogs, like WPTavern, for example, to tag posts with people’s names.

DREW: Sure.

PIPPIN: You could go in and you could view the Justin Tadlock tag on WPTavern and view all the posts talking about him or related to him in some way. Something cool that you could do then is to show an image in that archive of Justin Tadlock because it’s about him.

DREW: Right.

PIPPIN: I think that would be cool.

DREW: Yeah, and obviously that’s a really simple example.

PIPPIN: Right.

DREW: I think we’re going to see some really interesting sort of mind bending things going on like, “Oh, I could totally do that now. That’s amazing!” We’re not going to know what those things are until people do them. I think that’s what happened with post types, and it’s going to happen again, and it’s going to be really exciting.

PIPPIN: That’s one of my favorite things in development is that you never know how somebody is going to use it, and people will use whatever feature you build in completely unexpected ways. That’s cool.

DREW: In some cases, that’s the goal, right? In other cases not so much.

PIPPIN: Right. In other cases its’ the, “Why did you do that?”

BRAD: Unintended consequences.

DREW: I tell people this a lot and that is, they ask why we don’t just add hooks for all the things in core. My response to that is I documented all of them or I helped document all of them, and now I don’t want to add any new hooks because I recognize that we have to support them forever.

PIPPIN: The first time you introduce a hook that then gets used for unexpected reasons and cause unexpected consequences, you start second-guessing whether you should add a hook in places.

DREW: That’s just the example. I think it’s really just you should think about what you’re introducing. But, in this case, I think that was absolutely a good call.

PIPPIN: I had a perfect example where that happened to us recently where we have a hook inside of EDD. It fires during the process of verifying a download link. That hook got used for additional verification or error messages in extensions. The way that it was used actually completely broke our ability to introduce a new feature because we couldn’t introduce the feature because it was broken by the usage of that hook. That was completely unexpected and a little bit unfortunate, but that’s just the way it was.

BRAD: Right. I remember having a conversation with one of my developers about that because they were using hooks everywhere. Instead of just calling a function, they’d just use a hook because it was super flexible. I was like, yeah, that’s probably not a good idea. Do we really want people in there hooking into this because that’s what’s probably going to happen? Yeah.

PIPPIN: Drew, it’s been awesome. We probably shouldn’t keep you too much longer. It’s been great to have you on. Thank you for all of your insight and for everything that you do. Keep it up.

BRAD: Yeah, thanks a lot.

DREW: Absolutely. Thank you for having me. I love Appy Filters, so this is an honor.

PIPPIN: Glad to hear it.

Let’s give a quick shout out to our sponsors, the WP Ninjas. I want to highlight something that they just released recently.

BRAD: Oh, man, it’s so cool!

PIPPIN: They are previewing 3.0 of Ninja Forms. Something that’s really cool that they’ve done is they’ve decided to hire a design or UX agency to completely help them to rebuild their UI and to rethink.

We have some standard UIs in WordPress that we just expect, and they brought someone in from outside and just said, “Let’s throw all of that away. Let’s still build something that works really, really well, and let’s see what happens.”

They previewed it, and it’s really cool what they’ve done, so go check out their Twitter feed. I think it’s @WPNinjas on Twitter. They’ve got some cool stuff, so check them out.

BRAD: I couldn’t find a tweet that had that video in it besides James’s private–

PIPPIN: I found somebody that replied to that question asking where it was, and they linked it up.

BRAD: Oh, did they? Okay.

PIPPIN: It is also on their YouTube channel, so if you find them there.

BRAD: We’ll add it to the show notes too.

PIPPIN: There we go.

BRAD: Yeah.

PIPPIN: Yeah, so anyway, WP Ninjas have been awesome. They’ve been instrumental in helping us keep the show going, so go check them out.

BRAD: All right. Thanks, everybody.

PIPPIN: Thank you.