On Trying, and Failing, to Contribute to WordPress 4.0

Upgrade are failed | WordPress contributor fail

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.

Background

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.

IRC chat

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.

WordPress documentation team IRC log

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:

  1. Survey users to see if a broad base of support existed for a text review.
  2. 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.

WordPress dev IRC log
After a long technical chat to clean up remaining issues in 3.9, Andrew Nacin opened up the floor for ideas for 4.0:

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:

WordPress dev IRC log

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.

General thoughts

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


6 Responses

Comments

  • Fred, thanks for sharing your experience. When you posted your original article on the need for a style guide I agreed with the bulk of it. I have to say I was taken aback my Matt Mullenweg’s response. It seemed petty and like he was taking it as a personal affront. I participated in your survey and came down in favor of consistency, increasing helpfulness, and less use of local idioms. So I am happy to hear that you put your money where your mouth is and continued to pursue this.

    I agree with your take-away points, especially the idiosyncrasies of the IRC chats and the need for persistence. It seems that there’s enough interest in improving the tone of the text in WordPress that it warrants continued consideration. I think it’s a matter of keeping at it until you win over some of the influencers one-on-one. Once you’ve accomplished that ask them for guidance in how to proceed. Also, use the http://make.wordpress.org/core/ site to help get the topic on the IRC agenda prior to the start of the meeting.

  • Excellent article, thanks for sharing your experience – and caring about a better WordPress!
    I always impressed by companies like Apple, who are very serious about every detail go their products – the “perfect” user experience is the goal.
    I agree with your opinion, and those text should change. Cheers.

  • Although I haven’t followed this particular project much, one of the things that I’ve observed by paying a bit more attention to core over the past year (as a passive observer for the most part), is that there are all kinds of improvements and patches and issues that are valid, important and in a vacuum really merit inclusion and attention.

    I think the issue is that there is rarely instant gratification when it comes to wanting some feature/change implemented or bug fixed. I’ve noticed a bunch of things that core developers are passionate about, but a ticket status can last for years without landing in Core. I think the core devs have more patience in that regards because a) they stick around a long time and b) have a better sense of all the priorities that are being balanced from one release to the next and c) there is a natural benefit to being a core dev ( and so there should be) in being able to have a bit more influence. Nevertheless, WordPress does get better with every release, it just can’t do it all at once.

    What I take away from that is that motions to improve certain areas aren’t a lock to be included in a particular release. A lot of things need to come together. I think that makes the whole process quite off putting for people that are new or are just looking to get involved. Especially when other features do get fast tracked. It’s not a perfect process. I think the best way to get instant gratification for feature improvements in general is to find a way to do it in a plugin first.

  • Fred Meyer Fred Meyer says:

    Thank you guys for the thoughts! Really appreciate it. Have also heard a lot from Reddit people, as well.

    The overall takeaway, I think, is to be persistent if you want changes made in WordPress—which is a pretty healthy requirement, although I do also think that some of the ways into the process can be disorienting.

  • Ulrich says:

    I agree with 3 points of your conclusion. I am not sure that I agree with the second point as that is more your perception of the situation which you mentioned.

    An additional point that I see is that the change is too big. It is important to break the changes you want to make into smaller parts.

    You have three things that you want to solve.
    1. Define a writing style guide
    2. Change the current writing style guide
    3. Change the messages to fit with the new writing style guide

    The first solution should be able to be done with a simple ticket. I would think Meta Trac might be the best place. – https://meta.trac.wordpress.org/

    Make sure to include example like https://www.drupal.org/style-guide/content and
    http://make.wordpress.org/docs/handbook/references/handbooks-style-and-formatting-guide/ as refernces

    You do not want to mention about changing the style guide but just defining one.

    In one way you did receive an answer from Matt (Core Developer) on changing the style guide and the answer was no. It will be difficult to change Matt’s mind. What you could do is go to a contributor’s day where a core developer is around and in the best scenario a doc leader also and discuss the idea with them.

    To gauge the demand you could create a style guide and start a translation process. You then create a plugin and include the translation which people could easily activate.

    I encourage you to have another go at contributing to WordPress.

    ——–

    I agree with WordPress is not a democracy. Managing an open source project is not easy. I think there is much to improve. I think the underlying question is what management system works best for WordPress. There are organisation that function well under a single director, a board of directors or a democracy.

    Here are some interesting articles how WordPress management works and also accepting general code changes.

    https://github.com/WordPress/book/blob/master/Content/Part%204%20-%20Building%20WordPress/chapter-9.md
    http://nacin.com/2014/02/07/how-wordpress-chooses-committers/
    https://pippinsplugins.com/code-changes-hard-get-accepted/

    • Fred Meyer Fred Meyer says:

      Hi Ulrich, Just wanted to (belatedly) thank you for your well-thought-out response. Great links at the bottom as well.

      I agree with the main point that small incremental changes are a lot more likely to get initially implemented, although this is a shame if you think that a single structural change would be the best way to handle a lot of small individual cases of something.

      At any rate: thank you again!