On Trying, and Failing, to Contribute to WordPress 4.0
The WordPress 4.0 beta is out, and the changes look amazing. In particular, the media library “grid view” is an improvement I never knew I desperately needed.
WordPress 4.0 also marks the first WordPress version I tried to contribute to. I failed. I thought this could be a good time to describe what happened; ideally, this could help potential contributors understand how to approach the process, and also make contributing more open and inclusive.
In March of this year, I wrote a post describing what I think are problems with the tone of parts of WordPress’s written content, and recommending a community-approved writing style guide to review the content. The post drew a lively discussion, including this comment from the founder of WordPress, Matt Mullenweg:
WP has always been optionated software with a lot of personality. Every year or two people try to neuter it, remove a bt of its soul, and sometimes it gets through. There are always convincing reasons, like this post, but it’s sad nonetheless. If anyone is going to stop using the software over these we probably didn’t create something very compelling in the first place. You could also create a “dry” localization of the software and see if it gets much traction.
Andrew Nacin, the lead developer of WordPress 3.9 and several prior WordPress versions, also read and commented on the post.
Following the post, I was contacted by a number of WordPress developers interested in reworking elements of WordPress’s text content. A handful of developers were willing to commit time to the project, and we held a few Skype meetings to discuss how to move the project forward. One developer volunteered hosting space, and I wrote out the beginnings of what I believed could be a good tone and style guide for WordPress, with the intent of starting a document that the WordPress community would collaborate on, and that would eventually be incorporated into the WordPress project itself (likely as a new WordPress Handbook).
Documentation team chat
I was also contacted by one senior WordPress contributor, who had some suggestions for the possible tone review project. She suggested that I join a weekly meeting of the Documentation team, which handles the WordPress Handbooks, Codex, and inline documentation. On March 21, the Docs team put “Core Style Guide” on the meeting agenda, and I and another developer interested in a tone review joined the meeting.
Since WordPress contributor meetings involve potentially dozens of people, they take place over IRC chat. I found the IRC software initially difficult to understand and use—it’s a “precursor” to just about every other form of text chat, and still has some of the rough edges I remember from my childhood. Furthermore, most of the people in a given chat know each other, and make a lot of shorthand references and in-jokes that I found bewildering.
All WordPress meetings are logged, at https://irclogs.wordpress.org/. (One more reason WordPress is wonderful is that it keeps these logs; I foolishly didn’t save them to my own machine, but of course they’re publicly logged because hey, it’s WordPress.)
The Documentation team meeting I attended is logged here. You can see the parts I was able to participate in by searching the page (Ctrl+F or Cmd+F should do it) for my username, “fredclaymeyer”. I’m also pasting in a full excerpt as a screenshot below; you can click to enlarge.
Notes on Docs team chat
I really appreciated that the Docs team made space for this, and they gave a lot of really helpful suggestions.
The main piece of feedback was “get buy-in from core contributors,” as in this excerpt:
sams: Which part should be a community discussion?
fredclaymeyer: The tone we’re aiming for
sams: I think that’s up to the lead devs too, if you want to get any changes in.
The Docs team also suggested that we try to advocate for these changes in the main Developers chat, when the Dev team was ready to begin work on WordPress 4.0.
Following this meeting, we developed a two-part plan:
- Survey users to see if a broad base of support existed for a text review.
- Based on the survey, attempt to convince core contributors to make the review a priority.
Following this meeting, I published a survey on the written tone of WordPress. Most survey respondents wished the written tone were more “helpful” and “consistent.” The survey also highlighted the difficulty that highly idiomatic American English phrases like “howdy” pose to nonnative and non-North-American English speakers.
Following the survey, I contacted a number of key WordPress contributors, including Helen Hou-Sandí (mentioned as “helen” in the chat), who became the lead for WordPress 4.0 and who has in the past written about accessibility and inclusion in WordPress. Unfortunately, I was only able to contact her after she’d been named as 4.0 lead, so she was presumably swamped. I didn’t hear back from the other core developers I contacted, either.
Dev team chat
The survey finished around the time 3.9 was wrapping up, and I and another interested developer were luckily able to attend the April 23 Development team IRC meeting, at which people discussed hoped-for priorities for 4.0.
The full log is here. I’ve pasted in two screenshots based on the two times I participated.
nacin: anyone else have anything on their mind?
A number of people jumped in with ideas for 4.0, and I did as well:
fredclaymeyer: I’d like to work to create a more consistent tone for the text content
This was completely ignored, and after a few minutes it was clear it wouldn’t be returned to.
Around ten minutes later, I saw an opportunity to bring the subject back up:
Excerpting from the thread above:
nacin: if you are interested in claiming/maintaining anything on http://make.wordpress.org/core/components/, please let me know
kimparsell: nacin: I don’t see the Text Changes component in that list
nacin: indeed, it was possibly going to become a focus so it got avoided for the moment
kimparsell: nacin: Ah, that explains it. Thanks 🙂
fredclaymeyer: nacin: I’d like to help with that
nacin: fredclaymeyer: with?
fredclaymeyer: Text changes
[after a 40-second pause…]
jeremyfelt: ooh, I found the secret door
nacin: secret door? 🙂
jorbin: I also found the secret door
RDall: First magic now secret door? Seriously people we need to talk about these terms…
After being ignored a second time, I didn’t try to participate further in the meeting.
The “Text Changes” core component
The “core components” are a set of repositories for Trac tickets, broken out by subject. kimparsell was referencing the fact that, at the time (and currently), no Text Changes Trac tickets could be submitted.
Nacin’s response was that text changes seemed likely to be a focus in 4.0, so the component had been pulled in preparation. This seemed like very good news to me: it sounded like the decision had been made to favor the kind of formal review process we were advocating in favor of a bunch of one-off Trac tickets.
However, after being shut down in the 4.0 planning meeting (and hearing no response in my follow-up emails to several core contributors), I started to wonder if the module hadn’t actually been pulled to prevent text changes gaining momentum. Matt’s chilly response to the initial article made me wonder if he or another senior member had asked for the component to be removed. I’m still unclear on this, so if a Core contributor would like to debunk this conspiracy theory I’d be really relieved.
At best, sitting in on Core development felt like watching a close-knit community of experts step up to make WordPress better. At worst—and, in general, when I myself tried to participate—it felt like fighting a losing battle to convince a large, clubby in-group to care about an issue that wasn’t on its institutional radar.
I think the overall experience felt awkward and misfitting for a number of reasons, very few of which feel like “blame WordPress” in my mind. Here’s what I came up with:
- Open-source is not, and can’t be, a democracy. Anyone can participate in open-source projects, but like any other project they need a decision-making hierarchy led by a core of committed, knowledgeable people. Getting this core to pay attention is a political process like it would be anywhere else, and suffers the same potential for bias and arbitrariness.
- Technical people prioritize technical problems. In my conversations with WordPress developers and the one core contributor who responded positively to the idea of tone changes, I felt able to effectively communicate why I thought a tone review could improve WordPress as a whole. In other contexts, however, and especially in the Dev IRC chat, I felt like I was speaking a foreign language: the main topic of conversation was technical issues that I only dimly understood, and bringing in “polite, thoughtful writing” as a priority felt silly and off-topic, even though it shouldn’t have.
- Groups form when people work together. When people work closely together on a project they love, they become friends, and they also develop a shared knowledge base that they are able to take for granted. The net effect is that they begin to speak a language, and use tools, that only they understand. The IRC meetings are the most efficient way I can imagine to meet about building WordPress core; but I found them very hard to navigate, in both the technology used and the content and etiquette.
- Changes take grit. I’ll close with the consideration that I, personally, wasn’t gritty/loud/obnoxious/persistent/insistent enough to get a tone review through. I found the political side of the process confusing when someone else might have found it energizing; and, given my responsibilities to my career and my outside life, I probably didn’t have the time, passion, or commitment to force these changes into the world when the going got rough. So this and similar projects would benefit from someone bullheaded.
To conclude, I’d like to thank the WordPress community, which is the best or among the best open-source projects in the world. And a plug: if anyone still thinks WordPress text content could use some love, I’d be excited to be part of the process. I may not have been a great navigator of the open-source process for 4.0, but there’s always 4.1!
Image credit: Collin Anderson