Should we continue to support Discourse AND Slack?

Users
1

I’ve been divided about this for many years. In fact, we “tried” to move away from Slack for our open source users years ago, as you can see in this note:

https://dgraph.slack.com/files/U13LHF42F/F9R3QBKLN/Switching_to_discuss?origin_team=T13MNTQLC&origin_channel=C13LH03RR

However, now that we’re doing a renewed focus on UX, I’ve started to think about how can we provide an incredible experience. Discourse definitely allows us to keep track of questions better – while Slack messages can easily get lost in the pile. Even the solutions on Slack get unsearchable fast. OTOH, it has the power of “instant connection,” which gets more people engaged faster.

Also, came across this post: Effectively using Discourse together with group chat

In particular, this post by Sam, the co-founder of Discourse: Should Ember better define its use of Slack? - #66 by sam - Meta - Ember.JS , which correctly says that the community would go where the core team is. The feature set of the tool wouldn’t matter – and this is true for say Hacker News, Reddit, etc., none of which are chat platforms.

And apparently, Ghost moved away entirely from Slack to Discourse after they hit 11K folks on Slack: https://twitter.com/JohnONolan/status/981534715806191616

Of course, building a community anywhere is hard, and it has taken a lot of time for us to build our community on Slack. But, I think we should carefully weigh the effort required to maintain the Slack community against the user experience we can provide to our open source users.

Edits

May 27: Is group chat making you sweat? - Signal v. Noise
May 28: Motivation behind Discourse

2

I assume this is just for our open source community, and not for our internal team (as suggested by the Ghost thread)?

My thoughts here (caveat, I haven’t had the time to read all the linked material):

  • In 2020, it’s actually a lower barrier to entry for people to create a slack account than to use discourse, because everyone is familiar with slack
  • But 99% of those slack accounts are dead after they come and ask their first question. In the time I’ve been at dgraph, I’ve already created a ChartIO discuss account, as well as for one other, which I never logged into more than once
  • OTOH, we don’t get any metrics from slack as to how many questions were answered, which I guess we can track easily with discuss.
3

Yup. Purely talking about the open source community. Internally, we are judicious about what goes on Slack and what on Discuss, so we have found a nice balance there.

I’d argue that account creation itself is easier on Discourse than Slack, because Discourse allows logging in via Facebook, GitHub, Google, Twitter, what not. While on Slack, you have to set a password, verify email and so on.

Though, I’d also put the account creation as a non-factor. That one time effort when you need help with Dgraph is not such a big deal.

4

While slack comes across as an easier interface (arguably) to ask questions it is unstructured and rather difficult to track and manage. Everyone would have to scroll through the entire feed and make sure they didn’t overlook any significant question. Building metrics on user questions raised on slack is going to be a challenge.

Discourse is well structured and captures questions and answers in a thread. It also allows us to identify and summarize the discussion at the top (useful for important questions when a discussion has 50+ replies). Easier to scroll through the home page and identify hot questions and questions that have been ignored

In addition having multiple similar places where users can raise questions increases our overhead in tracking and responding to issues. Users have a choice on using multiple platforms (slack or discourse) but don’t appear to gain anything

3 Likes
5

I understand why this is true in-theory, in practice, Slack is now a tool that everyone is familiar with. It’s basically replaced IRC/FreeNode. As a user with a problem, discuss gives me very little over stack overflow. They are both forums. Slack looks like chat, so it feels more realtime. The barrier to entry is definitely lower. Again, I know that i’ve joined dozens of Slack channels which are topical (Ruby, Clojure, Kube, ChartIO, RailsGirls, etc…). Plus slack does that magic link stuff so that I’ll get notices on my phone.

I do not know why this is true, I don’t have a wall of stats to point you at, but people love to be on slack. Maybe it’s just familiarity.

I don’t think I’ve ever signed up on a forum.

6

As a Slack User, for communities like Kubernetes, Chef, Spinnaker, Slack is great, and there are various channel SIGs we can get into, where you will find other users that have expertise in those channels.

Certainly, search in slack leaves a lot to be desired, but I am not expecting chat forums to be used for knowledge management.

Slack has potential to create self sustaining community, with users helping users, future consultants or partners that collaborate with us helping users in addition to dgraph helping users and sharing interests, creating enthusiasm. Don’t see that with discourse (or other similar solutions like google groups), which is more formalized than ad-hoc discussions.

As Dgraph staff supporting users, discourse is easier to support users, as it is easy to miss stuff that flies through slack, for supportable events.

7

I am not against Slack. But I think the priority should be Discourse due to hundreds of factors.

The bad thing about Slack is that users demand an almost immediate response and that brings a little frustration to them. Some users even try to get support directly (DM). With questions that would gladly be asked on Discourse, as other users could use the Discourse search engine and get the solution without having to ask a new question (many users research old questions, I’ve been asked for questions answered in 2018 - e.g.: “This 2018 solution helped me, but is there a better and more efficient way?”)

Another problem is that in fact Slack has an audience and some users prefer it. So in a way it is bad to abandon it at once.

We can maintain a “Please ask at Discourse. Your question can help others” policy. And keep the other channels low priority. Or for chat.

I agree with it. Slack is very annoying on this. As simple as it may seem, it is boring at times. And when you use the “magic link” it opens absolutely all the slacks that you once signed up for. Slack was once an interesting thing. Today Discord looks much more interesting. For the newest dev generation*.

This is another point in favor of Discourse. Searching on Slack is confusing at times and it is limited for non-payers. That is, all users if they want to search the vast conversation wall. They will have to pay. Not at Discourse, we maintain the service. So it is free.

3 Likes
8

Look what I got from my inbox today :point_down:

Only scan it through for now, but want to share it with the group to help make the decision.

9

I am a huge proponent of deleting stuff (be it code or as in this case, tools.).

Discuss is where my vote is. It is a very clean interface in QnA format. Search is superior and a particular comment can be marked as Solution which is helpful as well. From a user perspective, I believe Discuss will be superior as well for focused, topic-related discussions.

Slack is a wall of IMs and hard to weed through. Threads are awkward/poor as Topics’ equivalent. A lot of context can be lost. Users that need really quick and simple answers may use Slack but anything that is more involved, they’d have better success with Discuss by creating Topics, Uploading data and reaching a Resolution.

As @MichelDiz mentioned, we can start re-directing users to Discuss and leave slack for simpler community chat before pulling the plug in say 3 months.

2 Likes
10

I’m not disagreeing with the majority of points here. Discuss should always be given priority over slack. However, I believe we should continue to support slack for the following reasons

Keeping Users First

Slack is popular for a reason. It’s easy to use, and end user friendly. I think the testament to that is how many users post on Slack every day (I believe slack out numbers discuss today, I see 6 new slack threads yesterday, v/s 1-2 that I see on discourse). It definitely is harder for people to manage. Looking at our core values, I’d argue moving away from slack is not in the theme of having an incredible user experience. We should go where the user is, not ask the user to relocate.

Put in another way - Discourse is like Google Plus. I guess technically it has everything that Facebook has, and is more powerful, but it’s just not where the community hangs out.

Growing A Community

Generally, i believe the lower barrier to entry, and the more fun-like the system you are using, the stronger a community you’ll build. I got into programming by lurking on various channels on Freenode (IRC) ~ 2004. It was actually fun to be there.

Chat has a much lower barrier to entry than forum posts, and you actually have the ability to have more realtime communication with people. And I believe that builds community in various forms.

Could this grow on a forum software? Maybe, but I don’t believe so. Discourse is super intimidating. We had a huge session to onboard our team to discuss. I’ve never seen anyone do that for slack.

And it’s very easy to DM people / set up private conversations in slack. I know you can do it in discourse, but it’s not as easy as cmd-t.

Altenatives to Slack Which Keep Chat

The majority of open source projects which I see having moved away from slack have moved to something chat centric.

  • Apollo did move away from slack, but to Spectrum https://spectrum.chat/.
  • The linked post (which spoke about how the community will follow the team) led to the creation of ember’s discord 0345-discord -
  • Hasura is on Discord
  • React takes you to spectrum

I’m hearing about spectrum for the first time, but one thing that is interesting is if it’s a single account across all your communities, so that dgraph becomes a channel, not a different account.

Data Driven

If we must shut down slack, can we at least do this in a more data driven way?

Rather than shutting it down, we can potentially stop signups, and redirect https://slack.dgraph.io/ to a message saying we are sunsetting slack, please join discourse. And let’s make a hypothesis for what we expect (ex: discuss posts per day should increase 80%).

If we don’t hit that hypothesis, we can roll back. (and if we do hit the hypothesis, we can go ahead and shut it down).

11

I tackle this point below about the effort required to provide consistently incredible user experience. Just having Slack doesn’t do that, we need to put a lot of effort to achieve it. If our aim is to provide this user experience, what tool we choose to provide it in, is really up to us.

I buy that Discourse is not for “hanging out.” It is aimed at getting your questions answered.

If a software becomes sufficiently popular, a community would grow wherever they want to grow. So, we would not need to have an official Slack or Reddit or whatever, the community would create all those mediums and thrive there. So, this is really about which medium do WE as a company, want to stand behind.

Agreed about the points that Chat has a lower barrier to entry than a forum. If I have a choice between a forum and a chat, I might just go use Chat first, and check out forum later. That’s a valid point.

But, how important is that point? If I do have a question I need to get answered, I’d go wherever I need to go to get it answered. On the other hand, if I just want to hang out, I might go to Slack.

Which leads me to think about the ONE main purpose of Dgraph team helping the open-source community? Is it to support our open source users, or to build a camaraderie? I think it is to support people, first and foremost. In turn, if they build a camaraderie, that’s great.

Side note: Typically my experience with Go Slack v/s Go Google Groups has been that Slack is okay for casual, simple questions. Email is good when you want some good answers from the team. So, over time, if I really want to actually get some solid responses, I’d personally shoot a mail to the group.

Questions to help us decide

So, I’ve been thinking how do we make a decision like this? I have come up with these 3 points:

  1. Can we provide a consistently incredible user experience (CIUX), based on the expectations that the tool sets?
  2. How much effort is it to achieve that incredible user experience?
  3. Can we measure engagement of our community on that tool? Can we get signals about what our community wants?

Let me try to answer those questions.

Slack (or other Chat solutions)

Slack can provide an “instant” user experience. Slack sets an expectation of quick replies, the SLA bar is strict. If you have to wait a couple of hours for a reply, that’s not incredible UX as per those expectations.

But, to provide CIUX, we would need to spend a lot of engineering resources on achieving those “instant reply” expectations. And its hard to know what’s been replied and what’s not in Slack. So, it creates a disproportionate effort to achieve CIUX.

Moreover, it’s hard to measure engagement in Slack. We don’t get much signals about what attracts our communities’ attention.

Discourse (or Forums)

The expectation set there is that the replies would come in at least a few hours. A conversation might last days. The SLA bar is lower.

Providing CIUX in Discourse, needless to say, it is a lot easier. Moreover, the search and recommendations when creating topics, allows the community to find similar topics.

We can easily measure engagement in Discourse. They have topic views clearly stated, so we know which topics are “hot” – we could then use them to write blog posts or create content. We can measure our response rates, time to first response, find unresponded topics and so on. It becomes a machine that we can crank.

If we shut down Slack

What do we lose by having Slack? Engineering effort spent on our open source community, all the past help provided and insights into what the community wants.

What do we gain by having Slack? Better camaraderie. By how much over Discourse? How much is it worth to us? What’s the practical value that it brings? I’m not clear on those.

Great idea. Let’s do it. Let’s stop signups for a bit on Slack and see if we see more signups on discourse. If we do this for a few weeks, we’ll get a sense for whether there’s more activity on Discourse, or we’re just losing those users altogether.

12

2 posts were split to a new topic: Experiment: Turn off Slack signups temporarily

13

A post was split to a new topic: Turning off Slack signups

14

yes , of course.
slack can have some bot.
you can use discourse as a train-data, and provide a chat-bot in slack .
your core team focus on discourse.
treat slack as a place for free talks.
people in community talk there.
If there some good idea on slack, then discuss on discourse.

16

It will be a HUGE mistake to shutdown Slack. This is where community is created and where people come to get answers in real-time. Though it’s nice to have Dgraph engineers available, it is not mandatory. Over time, as the Dgraph user community grows, this will be a thriving place to hang and talk Dgraph.

Slack can’t replace the forum and the forum can’t replace Slack. These are two different mediums to interact and get answers. I personally do not like forums (and I run one for Go). I like the personal interaction and the sense of community you get from a Slack group.

Dgraph can invest some time on a bot (we have one with Go) that could provide FAQ style support. Look towards the future of the user community growing and being able to support itself. Look towards the future of better documentation, more open source projects, and more people coming together in a community to help each other.

Your engineering team can make it clear that they are spending much more time answering questions on the forum. The Go team focuses their time on their mailing list. But don’t shut down Slack or not allow engineers who want to engage on a more personal level to help here as well. With the right expectation set, you can keep both platforms running.

6 Likes
17

Just for what it’s worth, slack is the entryway to most open source projects I use. It may not be a great medium, but it’s really fast to get set up, it’s asynchronous, and most importantly, it integrates with my existing workflows - I use slack for work, personal chats, etc, so that means if someone replies to me I get a notification in the same place I would for those other discussions.

I’m not a fan of forums. It feels harder to ask “beginner” questions, to iterate quickly on a conversations, etc.

I’d say if a software project has a slack I am ~10x more likely to consider that software for these reasons.

That said, I understand there’s a burden for these exact reasons. It’s a way for people to bypass higher quality messaging systems like, say, a templated Github issue. You’ll get “I can’t figure X out” type questions a lot. It’s the best/worst part of such a medium.

I can say as one example, I used to be quite active on Rust’s IRC channel when mozilla ran it and it was open without registration. They moved to Discord, and:I no longer participate. I actually hate IRC, but the fact is just that it was absolutely trivial to get started, and it integrated with my existing workflows, made it that much easier to work with. Rust also has a forum that is identical to dgraph’s and I’ve posted on it a total of, like, 5 times despite being an active user since just before their 1.0 release.

An alternative is fine, but I would I suspect any alternative is unlikely to simultaneously get at what slack has as benefits while also reasonably reducing burden.

Just some anecdotes!

3 Likes
18

Yes Tejas, exactly right! Let’s proceed carefully. I strongly value the conversational aspect of Slack - when the need warrants - and stick with forums for other community support needs.

19

For what it’s worth, I wholeheartedly support the decision to move away from Slack. While I can appreciate the desire for a realtime communication forum, I’ve always found Slack, specifically, to be very not-friendly and not-approachable for open source projects.

Reasons why:
Slack chat is not publicly visible. If a user has a question about a project or is interested in getting involved with the community, they are forced to provide their email address, respond to a confirmation email, and create an account with password all before they are even allowed to view existing conversations. This is an insanely onerous requirement.

Generally, if I’m new to a project and interested in learning more, I’m not prepared to “commit” to creating an account and jumping through hoops just to browse information. I think it’s important for the communication associated with an open source project to be open and publicly viewable, and Slack is not. While I appreciate the desire to foster a realtime communication platform associated with an open source project, I encourage the dgraph team to choose/endorse platforms that are publicly visible (such as this forum). Gitter would be an example of a realtime communication platform that you can browse without creating an account.

re: @gja a “In 2020, it’s actually a lower barrier to entry for people to create a slack account than to use discourse, because everyone is familiar with slack”

Everyone is not familiar with Slack. I am not familiar with Slack. I’ve always assume the divide is “people who use Slack at work” and “everyone else.”

re: @gja “But 99% of those slack accounts are dead after they come and ask their first question. In the time I’ve been at dgraph, I’ve already created a ChartIO discuss account, as well as for one other, which I never logged into more than once”

Exactly, the fact that you need to create an account to browse existing information is an insane requirement.

re: @mrjn “I’d argue that account creation itself is easier on Discourse than Slack, because Discourse allows logging in via Facebook, GitHub, Google, Twitter, what not. While on Slack, you have to set a password, verify email and so on.”

As a non-slack user, I wholeheartedly agree with this.

Edit:
I’ll also note that (I think) this is the first comment I’ve posted in the dGraph forum. I’m a living example of someone who is interested in dGraph, but who isn’t prepared to “commit” to it. I never would have found this thread, and posted my first comment, if it wasn’t publicly viewable for people without an account – simply because I wouldn’t have created an account. Though in my case, specifically, I had already created an account after finding a different thread that I wanted to follow some weeks back. Of course, I only found that thread because it was publicly viewable.

5 Likes
20

I agree.

When I joined, I went straight for Discourse as it was open and I didn’t need to jump hoops to read what others have written. Eventually I felt like making an account as well.

But I wouldn’t consider Slack, as I was overwhelmed by Slack at work, because of volley of messages I would receive on a daily basis.

I would wake up to someone saying that all the details are in so and so slack channel and I would have to go through that wreck of a channel to find a hairpin of information.

I hate e-mails as it feels like it will get lost without someone in CC to oversee communication, like it does when you apply to Google!

So Discourse + Gitter/Discord/Spectrum/Anything other than Slack will be a great combination.

P.S. Don’t use Microsoft Teams, It’s horrible.

3 Likes
21

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.