[Archive] Why Dgraph is Shutting Down Slack
This blog post was originally posted on Dgraph Blog. Since it was taken down, I recreated it from Wayback Machine and the corresponding Discourse post.
After 4 years of running Slack to support our community, we have decided to shut it down. July 14th would be its last day. Instead, we are doubling down on Discourse, the tool that powers our forum.
This blog post goes into the reasoning of how we made this decision. It contains an understanding that we could not find in any article, despite many online searches. An understanding that developed over the last 4 years of running both Slack and Discourse to support our community.
Don’t get me wrong. Slack plays an important role in the world. It was designed to be used by a small group of people within a company, provide them with real-time communication, and decrease reliance on emails. Slack has done that very well.
In fact, we are continuing to use it internally for our team communication. My narrative here is a critique at using Slack for running a growing community of users, and contrasting that with Discourse. In a way, this is an apples to oranges (chat vs forum) comparison, but it still is a relevant comparison to make. Which platform to choose is the decision many community drivers find themselves making when they want to bootstrap or evolve a community.
Some communities when moving away from Slack, switch to Discord and other online chat platforms. While I won’t be commenting on those other platforms just because we have no experience with them, most of the points I’m making here should apply just as well to other chat platforms.
Slack does not help build a Knowledge Base
Documentation of software is not just the official docs. It is also community-led knowledge sharing in the form of questions and answers.
Slack excels at one-on-one communication. It is typical for a user to post a question on #general. And at the first sign of a response, jump to have a 1:1 chat with the developer. That solves the problem for that user, but not for others.
Knowledge shared in Slack is lost. It is almost impossible to “mine” and re-use it. The context and the “thread” 1 are lost.
Contrary to the above, knowledge shared in Discourse exists and expands forever. It is easily searchable, and the context is not lost. It can be instantly useful to others, expanded upon, and improved over time. It is common for people to ask questions on year-old threads. Discourse has topic views clearly stated, so we know which topics are “hot” — we could then use them to write blog posts or create even more content.
The value of a conversation created on Discourse lasts years. Discourse catalyzes the creation of an ever-expanding knowledge base 2.
Slack does not produce more views
Can we get signals about what our community reads?
Slack defines an active user as a user who logged into Slack and read something. Most analytics platforms, including Discourse, use pageviews as a way to track reads, which is a better metric. Of course, a pageview does not translate well for a chat platform, which is why Slack has to use the active user metric.
Pageviews is a great metric. You can see how active the community is, whether logged in or not. Because Discourse helps produce a knowledge base that can be indexed and served by web search services, it provides an incredible value to the users. In fact, the “anonymous” pageviews in Dgraph’s Discourse instance is twice the number of pageviews by logged-in users.
On the other hand, Slack neither creates any content of long-term value nor can be used to view whatever content it has, without logging in. The overall result is that Slack does not generate more views.
Slack did not produce more engagement for us
Can we measure the engagement of our community on that platform?
We should define what engaged means. An engaged user is a user who posted something on the platform. A user who logged in and read is still an active user (as mentioned above), just not an engaged user. This metric is also not a count of how many messages were posted. If some excited user barrages the system with a lot of chatter, this metric can deal with that effectively, counting that user only once.
The theory is that the stupid-simple interface of chat systems makes it easier for a novice to jump in and ask questions. Consider the initiation of a new user. A simple "Hi, I'm new here" is a valid chat. On the other hand, forums can seem intimidating. Would a topic called "Hi, I'm new here" be a topic worth creating? Unless there already was a topic which encouraged people to jump in and say hi, such a topic would not be worthy.
Moreover, it is easier for someone to just “hang around” in Slack, monitor what’s going on, and jump in with suggestions. The natural conclusion from there is that significantly more people should be engaged on Slack than in Discourse. And that’s a common perception.
We found that to be false for Dgraph community 3. The number of engaged users on Slack was roughly the same as Discourse. That was not what we expected. This was even more interesting, considering that Slack has over 3K users, while Discourse has around 1.5K users 4. So, while more people signed up for Slack, around the same number of people were posting on Slack compared to Discourse.
Moreover, once we considered that our own team members were more active on Discourse than they were on community Slack 5, the numbers jumped strictly in favor of Discourse. Having more core developers on the same platform where the community is, is great. They are the experts.
Experts are the fuel for communities
Given enough experts, communities will thrive anywhere.
Users tend to go to the same platforms where the experts 6 hang out.
For large communities, this could be more than one platform as the number of experts grow to beyond just the core developers thereby allowing multiple platforms to self-sustain 7. However, smaller communities with only a few experts (notably the core developers) must pick a platform and run with it so as to not fragment the users.
Slack does not create a consistently incredible user experience
Can we provide a consistently incredible user experience (CIUX), based on the expectations that the platform sets? How much effort is it to achieve that incredible user experience?
Slack can provide an “instant” user experience. Slack sets an expectation of quick replies. If you have to wait a couple of hours for a reply, that’s not an incredible UX. However, to do this consistently, a lot of engineering resources are needed. Moreover, it’s hard to know what has been replied and what has not, resulting in a disproportionate effort to achieve CIUX.
It’s hard to even measure user experience in Slack. We don’t know which questions were answered. Once the chat logs go beyond the screen, they’re practically gone forever. Slack analytics leave a lot to be desired in this aspect.
Providing CIUX in Discourse, on the other hand, is a lot easier. The expectation is that the replies would come in at least a few hours. A complex conversation may last for days, without moving into a private one-on-one. The search and recommendations when creating topics, allows the community to find similar topics.
We can track our pageviews, time-to-first-response, find unresponded topics to ensure they get addressed, and so on. Discourse is an analytics machine that allows the developers to gain enough insights to continue optimizing user experience.
Slack does not support open communication
Slack’s single-threaded communication (despite channels) almost forces a user to switch to a private one-on-one conversation, to maintain focus. Multiple users jumping in with questions or comments at the same time causes information loss and confusion.
At Dgraph, only 30% of Slack messages are sent in public channels. 60% of the messages are one-on-one direct messages, while the rest 10% are private channels.
On the other hand, the structured nature of communication on Discourse allows the community to stay focused and open. Moreover, it allows the Dgraph team to use the same instance of Discourse for all internal communication.
Discourse naturally allows the development team to stay open in their development-related communication. For example, we recently created a dev category, where developers post their RFCs, design discussions, code-related questions, and so on. By sharing these topics openly, our community can learn from how we, as a team, operate. A community member can jump in with questions and suggestions, without interrupting the discussion, in fact enhancing it 8.
This level of sharing is possible in Slack but leaves too much room for sensitive data leaks and interruption. Therefore, the Dgraph team internally uses a different Slack instance. Many team members do not actively switch to and linger in community Slack to help our users. It is too disruptive for their workflow.
A compromise: The idea of keeping Slack around
Not wishing to make a radical decision and part entirely with it, a few popular ideas were floated to keep Slack around. One, get only a few developers to focus on community Slack. Two, ask the users to cross-post their Slack questions on Discourse. Or Three, the developers cross-post on behalf of the user for common questions. All these ideas have issues.
First, we would need to educate every incoming user that while we have two different venues for our community to interact, the Dgraph team is predominantly active on Discourse. Most users may not read such fine print, end up on Slack (well, it is advertised the same way as Discourse), and learn the hard way when their questions are inadequately answered or remain unanswered 9.
Second, a user who just signed up for Slack will be annoyed when they have to turn around and cross-post on Discourse. They might not understand why they need to switch to another platform.
Finally, Slack’s context-free log makes it tough to make sense of what people are asking on it over a period of time, hence it is hard to determine patterns. Therefore, converting a Slack chat over to a Discourse topic in any long-term meaningful way is just not possible 10.
One more reason we wanted to avoid keeping Slack around was that we had been there, done that.
I have some news to share. The Dgraph core team has decided to move off Slack… We’re going to keep Slack running, in case other members of the Dgraph community want to use it to help each other. — Manish and Dgraph Team, 2017.
We posted this note on our community Slack in 2017. To avoid making a hard decision to shut Slack down, we kept it around. Almost 3 years later, we can attest that nothing changed. Largely unaware of the note, the community kept on using Slack, and after some time, we jumped in to help them out.
Having learned from our attempts in 2017, we rejected any half-hearted solutions like keeping it around for some of us to engage. If and when the Dgraph community becomes big enough, it would have enough experts to use a platform best suited for them and sustain it. It would not need us, the Dgraph team.
Ripping the bandaid off
Simplicity is achieved by elimination. Determining what to eliminate is complicated.
While there were many voices internally, the decision came down to the 4 core developers who have been the most active in supporting the community. And the resounding consensus was to shut down Slack and focus our efforts on Discourse.
And with that, we have decided to shut down Dgraph Community Slack completely.
We have already turned off Slack signups 11. On the 15th of July, 2020, our community Slack would be shut down. We encourage our entire community to join https://discuss.dgraph.io. That’s the platform where we are committed to providing you our expert guidance and support.
This transition can be hard for some. And we understand that. There were many channels on our community Slack. We’d be happy to create categories corresponding to those channels, so our users can benefit from the focus categories provide. Just let us know which categories you want, and we’ll do our best to accommodate your requests.
Finally, on behalf of the entire Dgraph team, I’d like to thank our community for spending time with us and making Dgraph better software for everyone to use.
Top image: Space Shuttle Endeavour Comes Home to Los Angeles.
Slack threads are horribly implemented. So, I’m going to ignore them.↩︎
This knowledge base is even more useful for a small community, which might not already have third-party generated knowledge shared about it in the world.↩︎
Because this metric can be vastly different for different communities, take it as a “this is what we observed for Dgraph”, and not a generalization.↩︎
However, this might also be due to the fact that Discourse can shut down accounts that haven’t been active for a while, removing that account from the counting. While Slack would still count an inactive account.↩︎
This is also because the Dgraph team uses the same instance of Discourse, but a separate instance of Slack for team-internal communication. Using the same community instance of Slack for internal purposes is not possible for two reasons. One, we can’t afford to pay per member (there are over 3K members). Two, we need a lot of private channels for company communication that would be tricky to run alongside public channels.↩︎
Being an expert is relative to the wisdom that the community is seeking on the platform.↩︎
Even for large communities, the core developers might only be active on one platform — but a typical newbie might not need to talk to them. The sheer size of the community and the availability of “relative experts” on those platforms, allows it to self-sustain on other platforms.↩︎
If some posts are off-topic, they can be forked into a new topic or another existing topic in Discourse. That way, the flow of posts can be maintained on-topic.↩︎
Surely, there are other communities where this model works. Take Go for example. The Go dev team is largely active only on Google groups. But there are numerous other ways for the community to engage: Reddit, Slack, Discourse, and so on. However, if you look carefully, those other platforms are run by the community. The Go community is big enough that there are many experts available to sustain these platforms (see the section about experts).↩︎
Surely anything is possible if you throw enough resources at it. Problems only arise when you want to be resource-efficient. As Paul Graham says, “Mistakes seem to lose courage in the face of an enemy with unlimited resources.”↩︎
Since turning off Slack signups, we have seen a growth in our community engagement on Discourse.↩︎