WordPress, Openness, and Communication

One of the battles the WordPress.org project has faced since its inception is communication. Not just how much or how little but also the tools used to communicate. When I followed the development of WordPress with eagle eyes from 2008-2011, I used all of the communication channels that were available. IRC, the WordPress development blog, the WordPress.org forum, mailing lists, blogs about WordPress, and wherever else discussion on the core of WordPress took place.

There were times when WordPress appeared to be a completely transparent project. There were also instances when changes took place that were not communicated very well to the community that caused more harm than good.

Communication Featured Image
photo credit: elycefelizcc

Four Examples Of Communication Within WordPress.org

Siobhan McKeown, author of the WordPress history book has published a great post that looks at the openness and types of communication used within the WordPress.org project. She specifically highlights four different projects within WordPress. They are as follows:

  • Shuttle – Admin redesign project between WordPress 1.5 and 2.3
  • Redesign of the backend using design agency Happy Cog
  • Redesign of the backend immediately after 2.5 codenamed Crazyhorse
  • Redesign of the backend codenamed MP6

WordPress 2.5 Morphs Into Crazyhorse

I was one of the first to publicly view WordPress 2.5 redesigned by Happy Cog. It was released at WordCamp Dallas 2008 to cheers. Within a month, those cheers turned into boos. To the surprise of many including myself, the Crazyhorse project was announced soon after the release of 2.5.

Whereas the 2.5 redesign was done behind closed doors, a lot of work was done in the Crazyhorse to keep the community up to date. Significantly, a number of the key developers at that time feel that it was one of the project’s most exciting times, a point at which WordPress really grew up.

WordPress 2.7 Crazyhorse
WordPress 2.7 Unfinished Post Writing Panel

I agree that Crazyhorse was one of the most exciting times for the WordPress project. It’s one of the few times I remember witnessing a strong devotion to get the community involved in all aspects of the project with surveys and usability reports. Jen Mylo did an awesome job gathering community feedback every step of the way. The communication channel she administered between core developers and users is one of the biggest reasons I believe WordPress 2.7 was so successful.

MP6 Development Using a Skype Back Channel

mp6 plugin header logoMP6 was an interesting project to follow. Most of the communication surrounding the development of MP6 took place on a private Skype channel. Anyone could access the channel if they asked for permission but those chat logs are not searchable. They are not easily obtainable by anyone and it left many people wondering whether this type of communication is beneficial to the development of WordPress.

During Matt’s State of The Word presentation in 2013, Matt wasn’t sure whether the private channel on Skype was a good or bad thing. At the very least, reports of all of the changes that went into MP6 during the week were published on the Make.core.WordPress blog. The reports gave those that didn’t have access to the Skype channel the chance to provide feedback and be part of the development process.

Standard Status Report Of MP6
Standard Status Report Of MP6

Reports Are Boring But Are Publicly Available

There are those who believe that to be truly open source, everything concerning the project should be transparent. Others are ok with back channel conversations as long as the results of those conversations are published in a public location. Thanks to the success of the MP6 model, features as plugins first and other aspects of core development are being published as reports on the Make.Core.WordPress site. Siobhan made an excellent point regarding all of these reports:

The downfall of all this reporting is that it changes the public tone of the project from a conversation between community members, to a list of reports. The updates blog is particularly report-heavy, though many of the other make blogs are becoming that way. Reports are boring to read. No one wants to read a hundred reports. People want to be part of the conversation. Commenting on a report of a conversation that has already taken place elsewhere doesn’t make you feel part of things.

Complex Problem With No Easy Solution

I agree that reports are BORING. However, I’m thankful that the information in those reports is publicly available since I can not be part of the conversation. All it takes for me to keep up with a project is to keep tabs on those reports. The biggest take away from Siobhan’s post is that there is no tool or service that solves all of the communication issues within WordPress.org. It’s a problem that will continue show its ugly head. Thanks to Siobhan for putting the post together and showcasing just how delicate the balance is.

If you were in a leadership role within the WordPress.org project, what ideas, tools, or suggestions would you put in place to make communication accessible and easier for all contributors?


2 responses to “WordPress, Openness, and Communication”

  1. There is definitely a tricky balance to achieve between openness and also having the ability to have a meaningful conversation.

    I was in that MP6 Skype conversation since the beginning (I committed the very first version of MP6), and while there is nothing there that couldn’t be fully “open”, the question of whether it should be or not isn’t really the important thing. The important thing is the type of interaction involved.

    See, you can’t work with a thousand people at once. You just can’t. The dangers of design-by-committee are well known, but there’s also the issue of the number of voices in the room. If you have everybody talking at once, the conversation leads nowhere. Ultimately, somebody has to be in charge and making the decisions in such a large group and leadership becomes important, along with organization and everything else. But in a smaller group, say, 10-15 people, everybody can work together and at once without necessarily having well-defined structure or leadership roles. Smaller groups that are all on the same page can get things done quicker and faster.

    I think that’s the benefit of “private” conversations, they can be a smaller group of people, working towards a common goal. You get much more rapid iteration and active feedback. If everything had to be presented to a large group, then it would slow things down. Large group conversations take more time to gather and give feedback. Because of this, people in large group situations tend to work alone and only present final results to the larger group conversation, to avoid these time delays. It’s a natural response, when you share with the world, you tend to polish the work more. But when you’re sharing and working with just a few people, you can show half-baked ideas, thoughts, and concepts much more easily. Smaller groups tend to make progress faster because of this.

    I guess what I’m saying is that group dynamics is a fascinating subject, really. :)

  2. Most of your points here revolve around supporting arguments for adequately splitting up communication into sub-channels that aren’t flooded with thousands of people giving input, but that still doesn’t mean it’s a case for hosting those conversations behind closed doors, by invite only, and without any logs.

    We don’t send every reply to every ticket in the issue tracker to one single mailing list where everyone is required to sift through it to find the discussions relevant to them (and I don’t mean the firehose notifications here, that’s just a secondary feature for convenience). When you adequately split up discussion boards and mailing lists into sub-topics that evenly split the community up by interest (and the P2s already are), you can host very useful and controlled discussions completely in the public eye, where absolutely anyone that wants to be involved can speak their mind even if they aren’t writing the code themselves. Trac is actually the perfect example of that.

    Sometimes conversations become heated, and trail off-topic, as they do all the time on Trac and the forums, but proper moderation is the key, and you can still do that on mailing lists, and even P2s. When you look at the infamous LKML, completely public, with over 500 messages per day on a single mailing list, but consider that this is exactly where and how the Linux kernel is designed and developed (and even where you submit patches too), it’s actually pathetic to see WordPress denying the public access to spark new conversations or give feedback on one simple and small core feature plugin. In order for me to make one comment on something related to one feature I’m concerned about, WordPress now expects me to dive entirely in and become a full-time contributor to that feature or I’m not allowed to even join those meetings. I have to be a member of a team now. WordPress really has forgotten what it means to be an open source project.

    I wholeheartedly agree with Marko’s views on open communication:

    As for “design-by-committee”, you’re right, you can’t, but just because everyone can comment on some new feature doesn’t mean you don’t still have leadership. a democracy, or some kind of equal representation involved in making timely final decisions. It just means that the project has a chance to get a well rounded idea about where the *entire* community stands on something even if you can’t address everything and everyone. The most important part is that everyone is given the chance to speak and be heard.

    You can’t do any of that on Skype.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: