In this post:
Understanding the "bias of the loud" in a community and what drives people to dominate discussions.
Tips that community managers can use in meetings to give all participants the chance to talk.
Balancing the voices in online discussions.
In any form of community management, there is very often the "bias of the loud." This is my name for it, it may have others. I’m sure a lot of people smarter than me have done studies on what metaphorically gets expressed in English as "the squeaky wheel gets the grease." We don't want our wheels ungreased, but it's also important to hear from the entire community and not just the loudest
Bias of the loud is the loudest voices in the community tending to dominate the discussions. The danger is that they will drive away other participants who have as much (or more) to contribute, but don't want to participate in a shouting match.
So, as a community architect, how do you balance different personalities and help all members feel heard?
Bias of the loud can happen anywhere
It happens in broader forums, like mailing lists, chat rooms, and social media platforms. Every community architect knows it: you can make the most benign, forward-thinking, positive announcement ever made in the history of all community announcements, and someone will find fault with it.
The "don’t look at the comments" admonishment didn’t come out of nowhere, either. Posts on blogs and social media platforms can be replete with people that have sincere issues with the statements you raise…and that’s separate from the trolls who seem to thrive on social chaos and destruction.
How do you, as a community architect, work with this kind of situation? To be clear, we are talking about people with differing opinions and expectations that tend to dominate conversations whenever they can. We are not talking about people in violation of any codes of conduct your project’s community has in place. If that is the case, the choice is very clear: implement the policies in the code of conduct consistently and fairly.
Working with yelly people
It’s tempting to take a non-committal stance and say, "Just let the yelly people get it out of their systems and move on." I’ll admit that’s an option I look at a lot because trying to resolve every counter-argument can be very, very tiring.
There are two problems with this approach. While in the short term, letting folks rant is beneficial for your peace of mind, over the longer term, the loud people in your community are going to feel unheard and will either get louder or leave the community altogether. There is a delicate balance here, because you may not want the loud people to leave, so much as just moderate their energy and approach to discussions.
At the same time, the quieter people in the community will continue to have the perception that these conversations are reflective of the entire community and that, if the loud voices are being unheard, their opinions will also stand little chance to be listened to.
This meeting will come to order
In the case of community meetings or other structured events, the very organization of these kinds of interactions work in your favor for achieving a better balance of voices. For instance, putting in a little effort to create an agenda for the meeting could go a long way to ensuring multiple people have a chance to talk about something, and not just one or a few people dominating an open discussion. (An agenda also makes meetings more palatable in general since attendees know what to expect and can set their expectations and prepare for the meeting accordingly.)
During the meeting, you may notice that the same people tend to pipe up with comments and opinions. Even if they are the expert in the topic at hand, be sure to invite others’ input as well, making sure that you specify alternate forms of input as well. Some people aren’t comfortable talking in a meeting, but if you invite further conversation in a chatroom or mailing list after the meeting, that might be an avenue they would prefer to use.
Other strategies might include:
Keep meetings short. If there is less time, meeting moderators are justified in keeping comments short, too, and asking for other opinions.
Rotate the moderation. If you let all members of a group take turns running meetings, it will introduce more personalities into a gathering, and let more people have a voice.
Make non-verbal communication easier. Not everyone wants to talk, no matter how much easier you make it for them. Be sure to have other forms of communication (synchronous or asynchronous chat) available for everyone in the meeting, and make sure comments in those channels are acknowledged and followed up.
Reduce interruptions. Make sure everyone knows not to interrupt others when they are speaking. This is not only polite, it also gives more confidence to those who might need the boost to speak up in the first place. You may have to be very proactive about this at the beginning, but with consistency, the rhythm should take hold.
Going with the flow
For unstructured conversations, such as those that happen on mailing lists, chat rooms, and in real-time events, ensuring all voices get heard can be trickier.
The most important thing to do is pay attention to what is being said and who is saying it. The "what" is fairly straightforward, this is looking for instances of the conversation that swing towards being insulting or degrading. But even that is not easy. A community that has a lot of snarky personalities is going to be difficult to monitor for genuine insults, particularly because you don’t know who people are receiving the communications from.
If you see an overabundance of personally directed humor in the project’s communication platforms, it’s a very good idea to at least check in with the group and individuals and make sure everyone is OK with that. Better, try to create a "social" channel where people can metaphorically let their hair down, and keep the tenor of other channels a little less informal.
As for the "who," you are looking for community members who are dominating online and real-live conversations. I would strongly suggest actually getting into quantitative analysis for this, too. The reason for this is because of confirmation bias. This can happen when a "quiet" person has a few comments in a venue or channel and your brain thinks, "OK, good, so-and-so’s speaking up." If you actually count, though, you could find that the quiet person may have only had a handful of comments, while others in the channel have had dozens or even hundreds each in the same period.
More inclusive approaches
If you do find such an imbalance, a proactive way to solve this issue is to participate in conversations and actively solicit input from a person who is not as active in discussions. You may not get a response, because maybe that’s what that person wants to do, but perhaps the effort will be appreciated.
Another idea would be to approach the people dominating the conversations and ask them to ease back on their communication energy. This is not an easy conversation to have because it’s very easy to get defensive and assume that some sort of censorship is taking place.
Being public and consistent about a "hear all voices" policy before having individual conversations like this can help. Make the discussion about the good of the community, not any one person’s contributions. This, coupled with consistent enforcement of inviting others into conversations, should start a pattern of more inclusiveness.
Finally, if people are still feeling unheard, you might start working to get them involved in projects where their expertise and knowledge is more dominant. This might seem like an anti-pattern, but many social gatherings tend to do this organically. People with similar interests will congregate in smaller groups and have more engaged conversations. In the case of an open source community, stronger collaboration should soon follow. Smaller groups tend to also be easier to balance conversations as well.
Balancing communications among disparate groups and personalities is not easy, and one of the most challenging things a community architect may have to do. Everyone comes to an open source project wanting different things, and making sure one set of desires doesn't override another set is critical to building a healthy community.
Above all else, encourage listening in your community. Even if you don’t have all the best practices in place, listening can go a long way to avoiding misunderstandings and miscommunications.
About the author
Brian Proffitt is a Manager within Red Hat's Open Source Program Office, focusing on content generation, community metrics, and special projects. Brian's experience with community management includes knowledge of community onboarding, community health, and business alignment. Prior to joining Red Hat in 2014, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.