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.
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.
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 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.
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?
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. :)