Degrees of Openness: Communication in the WordPress Community

Communication issues have affected WordPress throughout its history; it’s something that we’re constantly trying to figure out. We have to adapt to changes in development strategy, changes in technology, or changes in project members. Over the past few weeks I’ve been focusing my research for the WordPress book on designing in an open source environment. Redesigning the UI has always been a challenge, particularly managing the relationship between those carrying out the design and the rest of the community. Often the break points come around communication and it has been interesting to track the evolution of how design has been carried out in the project. Helen’s post yesterday made me reflect on these things in relation to the project today.

Differing degrees of openness

There have been four main phases in the design of WordPress’ UI; Shuttle, Happy Cog, Crazyhorse, and MP6. This doesn’t include all of the smaller refreshes that have been carried out, but they’re the big ones. In the chapter that I’m working on, I’ve wrote  a lot about the details of each of these projects so I won’t go into them too much here. What I do want to talk about is how each of these was structured and how those working on the design interacted with the wider community.

The first was Shuttle. This was a closed mailing list of designers who were working on redesigning the admin between February 2005 – May 2006, starting around the release of WordPress 1.5.

The mailing list was intentionally closed. People could request to join it but few people seemed to manage to do so successfully and most of the activity was carried out by three designers and two developers. I’ve spoken to most of those involved and the reason for keeping the list closed was that there was a danger of “too many cooks”; everyone has an opinion on design, whether they are designers or not, but not everyone has the nuance and training of a professional designer. It makes sense to try to control the “signal to noise ratio”. However, having three designers was still too many cooks, and a lot of time was spent discussing the finer details of the UI, rather than getting anything out. The problem was that no one had responsibility for the overall vision so no one was really steering the project. The project also caused some unhappiness within the community. There was a feeling that there was a “blessed” group of designers who were working on the project apart from everyone else; the designs weren’t being provided for feedback, and the designers were making big decisions about the project which no one else was involved in. There is a wp-hackers thread from 2005 in which this is discussed at length. In the end, the Shuttle project wasn’t a success – over eighteen months was spent on the redesign before a complete set of comps was produced and, while elements of Shuttle informed the design, in the end they never made it wholesale into WordPress. Most of those involved left the project feeling disenfranchised and disillusioned.

The next major redesign was WordPress 2.5, this time carried out by design agency Happy Cog. Whereas Shuttle was an attempt at open source design, albeit in a controlled and not-so-open way, the Happy Cog redesign was a traditional job in which an agency was tasked with reworking the UI. The IA work, user testing, and design was completely removed from the community, with the brief being that Happy Cog would produce the comps and the WordPress developers would implement them. The team at Happy Cog worked separately to the community. Though they were sensitive to the fact that their work would have an impact on a significant number of passionate users, they treated the redesign as they would one of their normal clients. Again, community members were removed from the process. And when the final designs were shared the response was decidedly lukewarm.

The next design phase started almost immediately after 2.5 was released. The Crazyhorse project was carried out by Jen Mylo and Liz Danzico (who had previously been involved with the Happy Cog redesign). In this project they went back to the drawing board, with intensive user testing that made use of the latest eye tracking technology. While the user testing took place in a research lab in New York, much of it separate from the wider community, the development blog was used to ask questions, to run surveys, provide screenshots, and to post the findings of the usability report. 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.

The most recent design phase was MP6, the project which resulted in the redesigned 3.8 admin. Its success also paved the way the new features-as-plugins model which has been at the root of a lot of recent discussions around communication. MP6 put into practice some of the best elements of each of these projects and built upon the worst. Like Shuttle, the designers involved all came from within the community and those designers were given a private channel, this time on Skype, to talk. Unlike Shuttle, anyone was free to join the design group – they just had to ask. What MP6 did right, and that Shuttle was lacking, was that there was a clear project lead (Matt Thomas) who had final say on decisions, providing the project with a clear, coherent vision. Like the crazyhorse project, the MP6 team reported back to the community on what they were doing. This created a sense of accountability to the community, and prevented the community from feeling that the group was somehow separate. Community members could stay up-to-date with what was going on, even if they weren’t involved with the project. And, even better, everyone was free to install the plugin and follow the redesign as it happened.

Types of communication

With the success of MP6, WordPress’ features are now being developed as plugins. This was announced at WordCamp San Francisco 2013. The general consensus in the community was that this was a great idea, or an interesting experiment at the very least. I remember thinking that it could potentially lower the barrier to contributing by creating a safe space where people could help in smaller groups and I still feel that that is true. IRC can be an intimidating place to raise your voice. However, people were, and continue to be, concerned that this new model encourages backchannels, and that these backchannels are proliferating. This is a valid concern – how can we encourage openness when we also encourage groups to work in private?

MP6 created a good balance – Skype chats combined with IRC channels and regular updates on the make blogs. This is the model that everyone is following and what’s resulted is countless reports across the make blogs and an unwieldy number of IRC meet ups – it’s pretty hard to stay on top of all of the things across the project.

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.

There is an overabundance of information posted in the form of reports, and it can be hard to filter through it all. Yet the fact of the information being out there puts the onus on individuals to filter through everything to find what’s relevant to them, divesting the groups themselves of certain responsibilities. It’s too easy to say “the information was there – you just didn’t see it.”

Too much Skype?

There are things that I hate about Skype. I find the proliferation of backchannels  creepy. There are backchannels to IRC discussions, backchannels to backchannels. Sometimes it feels like there’s a public surface while underneath there’s this precarious network of holes underneath. I hate knowing that while I’m saying something in public, someone could be commenting on it elsewhere. It’s like sitting in a room full of people having a conversation while one or two are texting each other a meta-commentary.

And yet, Skype definitely has its benefits and to just criticise its use across the project is to ignore the problems that it has solved. In interviews I’ve done with people from Europe, they’ve often felt cut off from the project because IRC meet ups invariably happen at a time suited to people in the US. This has caused people from Europe (and probably other places) to back away from the project because they feel cut off from the decision making. Skype solves this problem by creating an asynchronous communication channel. Even if a conversation happens when you’re offline, you’re still in the channel, still part of the conversation, still a consideration. Channel members can quickly ping questions to each other, knowing that (even if someone is away at that moment) a response will eventually arrive that will be available to everyone in the group. IRC just doesn’t have the same level of inclusivity on that level. People don’t leave IRC on all the time, and reading back through the logs is a pain.

As has become apparent, in removing that one barrier, Skype introduces another. You’ve got to know who to ask to get invited to the channel, you have to know that the channel exists at all. And just by virtue of being a closed channel of communication, it creates a level of exclusivity.

The new model also has the potential for  situations in which groups form under the expectation of creating a plugin for core, but who end up with little input from the core team. With Helen’s role in 3.9 to be keeping on top of all of the projects, it looks like that issue is beginning to be addressed. It’s important –  in the Shuttle project too much distance from core lead to a group losing track of the core product, the project failing and the group involved feeling disenfranchised.

Getting a balance

IRC sucks, and making a Skype channel is definitely easier. And there are times when it is definitely more appropriate. As a WordCamp organiser, I find Skype channels essential. Also, when you’re working in a distributed organisation, having channels open for just chatting and socialising or “shooting the shit” (h/t helen) are important. There are also alternative modes of communication that people are using – Google groups or Google messenger.

Sometimes it feels, though, that we’re swinging too far in the direction of relying on closed channels of communication for things that could be open. The reason for this in relation to design seems valid (that its easier for people to feel open in a private space) but it’s in danger of becoming the norm, rather than the exception. And while it may have worked for MP6, it’s not going to be right for every project.

Just focusing in on WordPress’ interface design shows how delicate the balance is: projects that have been too closed have resulted in failure. And, as wp-hackers demonstrates, too much openness and you end up with an unworkable signal to noise ratio. I don’t know what the answer is. Maybe IRC isn’t the right tool anymore, maybe it never was. Skype probably isn’t the right tool either. Not everyone uses Skype and it creates a new set of problems. Perhaps we need a new tool, to look for a new communication method we haven’t tried yet. Perhaps we need to try to use P2 in a new way. Undoubtedly, communication will continue to be an issue for the project, as it always has been, and whatever methods we’re using, we ought to be vigilant to problems as they come up, give everyone a voice, and try to keep people involved.