Splitting conversations splits community
Activity begets activity. When people see activity in a chat, mailing list, or forum, they’re more likely to view the community as active and thus worth taking the time to participate in. After all, why bother taking the time to craft a message that will just disappear into the void? Unfortunately, community leaders are often too quick to segment conversations into different channels, which effectively hides the activity in the community.
Real-life examples
I saw this recently with a community I’m a part of. The leader lamented that the mailing list was less active than he had hoped it would be. There was a burst of activity after news of significant changes, which prompted a few people to toss out ideas for the future of the project. The leader then created a new mailing list for people who wanted to participate in that discussion. It’s hard to reconcile the wish for a more active mailing list with the reaction to move a significant part of the discussion to the new list.
When I first started attending the LISA Conference (RIP), a lot of the backchannel conversation took place in an IRC channel. Most people were in the same channel, regardless of which talk they were attending. As a result, everyone could see what was going on in other talks and it built a culture of excitement. One year, Alice Goldfuss gave a talk that became The Talk™ that everyone wished they had seen. Over the course of the hour, people got more and more excited — especially those, like me, who were in another room. In later years, we used a Slack instance with more rooms. It wasn’t the same. (In part because some people were still on IRC, which is a future post.)
Why avoid splitting conversations
I understand the intent behind splitting conversations early. Everyone is busy and you want to be respectful of people’s time and attention. Nobody wants to be seen as a spammer.
But the community-building benefits of an un-split conversation are important, too. As I said above, nothing attracts and retains members like visible activity. This is the foundation of the Flywheel Theory of Community Engagement. If you want people to see your community as active and vibrant, they have to see your community being active and vibrant.
Unified conversation channels also lower the friction for sharing ideas. People can more easily notice a conversation and give useful input if it’s in the main channel. If the conversation is in another channel, they might not be there. In general, people are going to join channels that will be consistently useful. You miss out on good ideas — and don’t flag bad ideas — when the conversations are split off.
When to split conversations
In general, you’ll know it when you see it. The biggest sign will be that your active members start to complain about how “noisy” the channel is. This is usually due to either raw message volume or conversation specialization. In the raw message volume case, there are just so many messages that people can’t keep up. With specialization, you’re having a lot of conversations that aren’t relevant to some subset of the community.
I recommend starting with a single channel (or two if you want one for synchronous communication and another for asynchronous) for all conversations in the community. The first split that will probably happen is to separate user-focused conversation from developer-focused conversation. The developer-focused conversation might then split into developers and testers, or development for the major components of the project. For almost every project, two or three channels is enough, and for many projects, one is sufficient. Only the very large and very complex projects — Linux distributions, Kubernetes, etc. — will need to go beyond this.
This post’s featured photo by Mick Haupt on Unsplash.
