An interview with the Release Leads of WordPress 4.9

WordPress 4.9 hit the shelves last week meaning 29% of the web woke to a nicely wrapped package of code filled with improvements to the way they work with the Customizer, safer and clearer ways to work with code in the admin, and new and upgraded widgets. 🎉

To peek behind the curtain (which is nicely transparent in our world of open source), we’ve asked Weston, Mel, and Jeff, Co and Deputy Leads on the 4.9 release, some questions about their experiences on the project and their thoughts for where WordPress is heading in 2018.

 

Q: So how does one find themselves leading a release that impacts 29% of the web?

Mel: With a great sense of responsibility and a bit of trepidation. 😛 The customization focus has been somewhat “on hold” while work on Gutenberg progresses, but there’s plenty of updates we can make while we wait. It made the most sense for Weston and I to co-lead 4.9, so we could concentrate on making some site customization improvements and lay some groundwork for Gutenberg in the future.

Weston: This year is somewhat different than previous years in how the WordPress project has been managed. This is the first year we’ve had dedicated focuses (Editor, Customizer, and REST API) while also having releases that are more feature-driven than deadline-driven. In the past a call for volunteers would go out for a lead for the next release, along with some core team nominations for who would be recommended from among core contributors who have demonstrated their commitment and leadership in the project. Since the Editor focus is working in the context of the Gutenberg project and not core and since Mel is the design focus lead for the Customizer and I am the Customizer dev focus lead, it seems that we became the release leads by default.

 

Q: What is your favourite thing that went into the 4.9 release?

Jeff: Changeset drafting / scheduling/ previewing, as this was something my Team at XWP has spent a lot of time with over the past two years improving for clients as part of the Customize Snapshots plugin. So getting to see that land in core validates the hard work the Team did knowing it had broader impact.

Weston: The improvements to changesets, in particular the drafting/scheduling and frontend previews, as this is something we’ve been working on at XWP for years in the context of the Customize Snapshots plugin. It closes the loop on Customizer Changesets which were introduced in 4.7 and merged the key infrastructure from the feature plugin.

Mel: This is pretty small, but we worked with Michelle Weber, an editor at Automattic, to write and update a bunch of microcopy for the various areas of focus on 4.9. Copywriting is a pretty underserved area of core, and I think Michelle’s contributions really made an improvement to the overall tone and clarity in WordPress.

 

Q: What experience as release lead did you not expect or thoroughly underestimate?

Mel: Two things:

1. The amount of tiny decisions you have to make every week and how tiring that becomes.
2. How hard it is to convince volunteers to work on specific features

 

Q: What advice would you give someone who wants to lead like this in the WordPress community?

Weston: Find a component in WordPress that you are interested in. For me it was the Customizer. Start following the component in Trac to see the kinds of issues that are reported, who is currently contributing, and how the issues get resolved. Start testing patches that get added to those tickets, and start writing patches of your own to get feedback from the existing component maintainers. The more you become familiar with the component, the more you will master it and become recognized as an authority on it. Once this happens, you should become appointed a component maintainer yourself. When a release comes up that will focus heavily on your component, you will be a natural choice to lead the release.

Mel: Keep showing up! Folks who show up consistently and are reliable find themselves given more responsibility. Watch the Make blogs and Slack for a while, work on a couple Trac tickets, just keep making your face known. Be humble. Don’t assume you know everything yet. Ask about the history of a feature or a decision before jumping to judgement. Come hoping to learn. Be kind.

 

Q: Where did the vision and direction for the release come from? How do you, and the people contributing, decide what goes into a release and what doesn’t?

Weston: Matt had already identified Customizer as being a focus for the year. Mel and I brainstormed through various wishlists of customization-related issues that we’d like to get into a release, and Mel shared these with Matt to get his feedback.  We then published a release goals post for additional for additional feedback from the community and then pressed on with implementation. One key consideration is to have some big user-facing features that will get the end users excited about the release: after all, WordPress is all about the end users. So we need to make sure there are a few big ticket items that we can feature on the readme and release announcement posts. But then there are also tickets that focus on “developer happiness”. Some of the tickets that get milestoned for given release may not translate immediately into a user-facing feature when the release ships. Some changes require work over many releases to finalize into something the user will see. I think of the long road to get to taxonomy term meta as an example of this. Likewise, in 4.7 we introduced the infrastructure for Customizer changesets but only in 4.9 did this show up as a user-facing feature in the drafting, scheduling, and frontend previews.

Mel: What Weston said. 🙂

 

Q:  Jeff, what’s the role of a deputy release lead and what value does it bring the team?

Jeff: The deputy role is loosely defined, but the general recommendation is for deputies to augment the skills of the release lead(s). My experience as a deputy has been with release leads who are talented engineers and designers, so my product and project management background melds nicely with them. When I first began contributing to core as a deputy on 4.7, I was uncertain how a non-engineer could contribute, but slowly found areas that were “achievable” for me and “noise” for others. In detail, that general amounts to setting the schedule, posting agendas, running weekly devchats, posting devchat summaries, running bug scrubs, posting the field guide and any other documentation updates. I’ve found that taking those tasks “off the plate” for the release lead(s) allows them to focus more fully on product design and development. In general, it allows each person to focus on areas where they can contribute their highest value to the project.

 

Q: Mel, what was the biggest design informed win of the 4.9 release?

In usability testing, we consistently see people struggle with creating menus, and adding new pages to their menus in the Customizer. I’ve watched a bunch of usability tests where someone went to “Add new menu,” thinking it would add a new page to their existing menu.

To improve this experience, we worked with some support folks and a copywriter to come up with a more clear, guided flow for creating a new menu. It was great to tackle something that I’ve seen folks struggle with so many times!

 

Q: Weston, how do you consolidate the hundreds (thousands?) of code contributors and commenters into meaningful code? How do you pull the signal from the noise?

A lot of it comes down to the component maintainers. They are the experts on their respective areas of WordPress. Since they have demonstrated a reliability and have a proven track record, when they recommend a ticket it is noticed. When a ticket aligns with the goals of a release, then the release lead will likely identify it as something to be milestoned for the release. The release lead may or may not be experienced in the component. The release lead may not even be a core committer (though that would be unusual). Release leads depend on core committers who have “graduated” from being component maintainers to commit patches that have been recommended by other maintainers for the component.

 

Q: The attitude towards backwards compatibility has changed recently. What impact have we seen from this on 4.9 or can expect in future releases?

Weston: One of the things Matt said at his State of the Word in 2016 was,

“What got us here will not get us there.”

He said this in relation to taking WordPress from a quarter of the Web to the next, and making WordPress more design-lead rather than development-lead. WordPress faces a lot of stiff competition from other services that are able to move much more rapidly since many of them have closed ecosystems and they don’t have the baggage of a mountain of legacy code to maintain backwards compatibility for. WordPress will always have an open ecosystem, but what can we do about the legacy code that slows us down? This is somewhat where the REST API comes into play and the move toward JS-driven interfaces: we have an opportunity to do a reboot of sorts with a new foundation upon which we can build the next generation of WordPress, while we still maintain the old foundation for existing themes and plugins.

 

Q: What didn’t make it in 4.9 that you wish did?

Weston: Being able to schedule a change to a theme would have been really nice. Right now have to explicitly turn off drafting and scheduling if you’re previewing a theme switch because of some current technical limitations.

Mel: You can install themes from the WordPress.org theme directory in the Customizer, but you can’t install them from a .zip file yet. Also still really want to push for previewable site revisions (similar to post revisions, but live previewed).

Jeff: Updating plugins/themes via an uploaded ZIP file (#9757), as I love seeing those really old tickets getting attention and resolved plus this is one that has impacted my own sites in the past so I know end users would have really liked this one. The trouble is without someone owning tickets and working to get their code contributions into core many tickets like this one will languish. So to those reading, if there’s something in Trac that you’re passionate about then jump in and help however you can. We can’t do it without you!

 

Q: Customizer had a lot of focus in the 4.9 release. What is the future of Customizer, especially with Gutenberg coming around the corner?

Weston: The scope of Gutenberg is much larger than just the Editor. Since Gutenberg is really about introducing the new foundational concept of the block. While most of the Gutenberg work so far has been focused squarely on blocks living inside of post content, there is no reason why blocks can only live there. In fact, some work has gone into letting aspects of blocks be stored in postmeta, and there is also a wp_block post type for blocks to be reusable across posts. These reusable blocks will also then naturally be used as a next generation of widgets in sidebars. While the work in Gutenberg so far has focused on post editor context, the Customizer is all about the theme and overall site level. The Customizer at its core is just an administrative interface for making changes to a site’s state. Changes in the Customizer are made to options, theme mods, nav menus, widgets, and even posts and pages. These changes are staged in a changeset where they can then be previewed, drafted, and scheduled for publishing in a batch. The Customizer is already a JS-driven single page application and the components being developed in Gutenberg will fit naturally inside of it.

Mel: The future looks more consistent, more modular, and more documented. It should be easier for design-savvy site builders to create beautiful layouts from scratch, and just as easy for a busy business owner to make a new page on their site in a template that’s already been art directed, just waiting to be filled in with some suggested kinds of content. Folks won’t have to go digging through multiple levels of navigation to make a simple text or image change to their sites. A blogger won’t have to abandon a theme they liked just because they can’t rearrange or hide their post meta. The future will be faster, more flexible, and accessible.

Jeff: https://twitter.com/westonruter/status/606596357571276800

 

Q: Do shippers really drink scotch?

Mel: Yup. Proof!

 

Congratulations to Weston, Mel, Jeff and all of the other contributors to WordPress 4.9 for a great release. If you’re looking for ways you can help make WordPress better, here are a few ideas.