Should Ember better define its use of Slack?

[alvincrespo]

Just my two cents here.

At first, I thought real-time conversations for help in Slack was a good thing. To be honest, it’s nice to get that 1-on-1 help and get answers to questions/concerns quickly.

Over time, my mentality on this has shifted for various reasons.

1. It’s distracting to have another Slack group open at work
2. You develop a feeling of instant gratification over time (e.g. I need this answered now)
3. Knowledge transfer is non-existent (e.g. A question will probably be asked and answered with little to no track record)
4. It’s not beginner friendly

Let me touch on that last one real quick.

I totally loved the Slack channel and thought it was great for beginners, and I’ve definitely pointed people to Slack to ask for help. But that requires a lot of trust (new person) from people (ember folks) you don’t know. Personally, I’m very transparent but many people aren’t immediately and don’t want to create a new alias for themselves just to ask questions - initially. This changes over time, but it’s a big ask for newbies.

Either way, these are observations I’ve had. Hopefully, it’s useful in some manner.

Cheerios!

[davelowensohn]

Just want to chime in, on record, that my dev team talks about this a lot. We don’t think Slack is “bad” per se, or bear anyone any ill will for using it, but everything that happens there is inherently ephemeral and walled-off if it isn’t somehow archived and exported. This seems prohibitively tedious at the moment & I haven’t come across any examples of it happening - rather, I keep seeing the opposite, where a promising SO or forum thread from whenever ago will end with “Come join us on the Slack channel,” the internet equivalent of tire tracks going over a cliff.

My biggest concern isn’t that it’s hard to Google answers when I get stuck, but rather that the lack of a strong web presence means less overall mindshare, which means that #EmberJS isn’t trickling down to the kids or up to the C-suite as hard and fast as it should. Fewer pointy-haired bosses have heard of it, which means fewer job postings ask for it, which means fewer junior devs are learning it, which for me personally directly translates to (1) having to take Angular/React freelance gigs, because that’s overwhelmingly what keeps coming my way, and (2) having a really hard time finding other Ember freelancers to work with, on the bigger Ember projects that do show up, who aren’t either fresh out of code camp or basically members of the core team.

Nothing but love for the framework & community, just adding my $0.02 because this seems to be an active conversation about Ember in a widely-seen, non-ephemeral forum - exactly what I think we need more of.

[ef4]

I’m strongly in favor of doing more here in Discourse where it’s searchable and backed entirely by open source.

There are some useful ideas in this post about how the Discourse team themselves use it. Notably, they agree that having realtime chat for quick answers is still helpful, but needs to be treated as throw-away and anything else goes in Discourse.

[dustinfarris]

Another alternative is Keybase, who picked Slack’s defunct history as part of their pitch for their new Teams feature:

https://keybase.io/blog/introducing-keybase-teams

[eccegordo]

The long term usage of slack is a turn off. But ultimately this is a process question and not a technical one as there is a time and place for quick answer real time questions. I think perhaps we need to encourage participants who ask QA stuff on slack to take as action item a transfer of that info into Discourse/SO.

For example a back and forth question session on slack is great start and then once the “problem solved” restate in a QA form on the forum.

To this end I think a slack bot integration to facilitate this would be an excellent idea. MVP could be just copying the slack thread to a new post on discourse. It can always be further refined or curated on the forum, especially if a particular question gets popular.

And we should probably let popularity drive how much effort goes into curating any given thread.

[mattmcmanus]

As many have said, the utility of a tool like slack justifies it’s continued use in our community. But, I’m very much in favor of this conversation and look forward to what we all can learn from it.

There are many good points already mentioned above. I’d like to pull a thread that hasn’t been explicitly addressed. My thoughts revolve around two audiences: 1. new ember developers and 2. the larger javascript community.

The Learning team has done a fantastic job improving the guides to help guide new developers . However, there is no way they can answer every question, nor should the guides try to accomplish that. Having Slack as the primary channel for questions is not only intimidating, it’s inefficient. The signal to noise ratio is astronomical. This adds a lot of friction, especially in those critical early days of learning of the framework.

Another downside of our slack usage is that we’ve effectively walled ourselves off from the larger javascript community. I regularly have to respond to folks who say “I thought Ember was dead?” I believe that is a consequence of how much of our relevant, collective knowledge is not public in any meaningful way. This forum kind of feels like a ghost town. So many of the answers on stack overflow are from pre-ember-cli days.

The article @ef4 shared above about how Discourse uses Discourse, is instructive. Slack is ephemeral. The core team and addon authors should push Q&A to here or StackOverflow. It should not take long for the community to shift gears.

(Side note: I didn’t realize how capable Discourse is. Check out these two sections as potential sources of inspiration for here: https://meta.discourse.org/c/howto & https://meta.discourse.org/c/plugin)

I hope these thoughts are helpful. Go team!

[riking]

An important point to consider here is that Slack has been taking steps to actively push “open” Slack teams off the platform. This is most obvious with the pricing plans - $ per month per user - that is completely untenable for anything with open signup.

The pricing plan has been there for a while, but if you take a look at the more recent platform changes and the API blog updates, you get a sense that the company really doesn’t like the “open to everyone” teams. I think that’s a large part of why these conversations are happening right now as opposed to six months ago

[mcwumbly]

I think Slack definitely has it’s place and I renamed this thread to reflect that

I think the new name is a great way to frame the conversation.

I wrote the topic referenced in the original post a little over 2 years ago.

Some notable observations:

1. I wrote that 2 years ago, and you were able to find it and link to it here. Good thing I didn’t just post it in a Slack instance somewhere.
2. The original post is a copy of a conversation from Slack. Good job capturing that and getting a discussion going here where it can evolve over a longer period of time!
3. I wrote that 2 years ago, and it’s something we still struggle with

We have the chat integration plugin installed. Adoption of the “subscribe to a category or tag via slack” feature of that plugin is OK, but not great. The “post a transcript from Slack” is rarely used. In part because of the lack of thread support, but I think in greater part because chats just don’t transfer that well to this medium.

The more successful patterns we’ve seen are social ones, which is why I think the renaming of this topic is on target. What kinds of behaviors do you want to encourage and how can the leaders (formal or informal) in the community best model them?

Some things that I have seen work well:

1. Start the discussion on Discourse, and then share the link in one or more relevant Slack channels, inviting people to participate in the discussion who’s “canonical home” is on Discourse
2. When a conversation takes place in Slack that is related to an existing thread on Discourse, point out the link to the Discourse thread in Slack. Don’t try to move the conversation over while it’s in flight though – that’s often disruptive. Instead, if anything new came out of the Slack chat, summarize it in a follow-up post on the Discourse topic (in our case, we also encourage linking back to the Slack conversation, but we’re paying for archives… that probably wouldn’t be too helpful here).
3. When a discussion just starts to feel like it’s the kind of thing that may have lasting value, suggest moving it at some point, “Hey, this is some really interesting stuff, you should consider posting it on Discourse so it doesn’t get lost.” Natural times to do this include when people type multi-paragraph posts in Slack, but others will just be apparent, I imagine. Another example is when people work through something kind of gnarly troubleshooting wise (“hey, glad we finally go to the bottom of this, It’d be great if you could summarize the issue and the resolution for others on Discourse”)
4. Nudge people by making them aware of the value of asynchronous communication. “I’m kinda busy so I can’t help you right now, but if you post this on Discourse, I’ll try to answer later (unless someone else gets to it first.)”

Changing culture is hard, but I think that’s the necessary element to make something like this succeed, more so than any technical integrations.

[system]

Greetings from the Discourse team

First of all, thank you all very much for your insights! I’m going to be writing a blog post to clarify our stance on the whole “Discourse (forum) and Slack (chat)” conundrum. As you’ve already concluded, the short answer is: Forum & chat can and should co-exist perfectly well. It’s just a matter of recognising their individual strengths and weaknesses.

I only have one more thing to add to this largely complete discussion: I find it odd that no one brought up the fact that Discourse is an open source Ember application. discuss.emberjs.com is hosted for free on Discourse.org’s servers. If anyone ever wants to make a plugin to improve any part of your workflow, such as:

• improving our Slack integration
• making Discourse more “real-time” (for instance we recently added “Who’s writing” capability)
• integrating your Discourse with canonical resources in the Ember ecosystem, e.g. https://www.emberaddons.com/

then you can do that.

I’d also recommend replacing Disqus with Discourse on https://emberjs.com/blog/. There’s a lot to be said about Disqus but I’ll just boil it waaay down to: Open source (and Ember-app) is better.

[rwjblue]

Sooo… I’m sold?

Let me make a concrete suggestion, see if folks think its a decent initial step forward:

1. Make a Q/A category here (and make some subcategories for more common types of questions).
2. Update the channel topic in #-help (in slack) to point to this forum (recommending searching here as part of the troubleshooting process there)
3. As common issues are discovered during slack conversations and elsewhere we (as a community) try to take the time to discuss the issue here. This may just mean posting a quick summary and hopefully doesn’t need to become a burden on folks.

I think that this smallish step will ultimately make a large difference. What do y’all think?

[Henry]

It seems that Discourse allows topic templates. Maybe they would be useful to specify the Ember version used or any other relevant stuff.

[rwjblue]

I created a few initial categories / sub-categories and kicked things off with Questions? Bring it!…

Lets do this!

[alvincrespo]

Perfect! I it.

[mattmcmanus]

I’d also recommend replacing Disqus with Discourse on https://emberjs.com/blog/. There’s a lot to be said about Disqus but I’ll just boil it waaay down to: Open source (and Ember-app) is better.

I like this idea a lot. The more inroads to the forum, the better.

[rwjblue]

I’d also recommend replacing Disqus with Discourse on https://emberjs.com/blog/. There’s a lot to be said about Disqus but I’ll just boil it waaay down to: Open source (and Ember-app) is better.

@discourse - Any quick pointers on where to start with this? (or is it just as simple as RTFM…?)

[system]

Hopefully it’s as simple as following the docs, yeah:

Embedding Discourse Comments via Javascript

Just follow up in that topic if you need more pointers or something’s not working right.

[sam]

I think that this smallish step will ultimately make a large difference. What do y’all think?

One thing to keep in mind here which is super important, people will go where the core team / key members go. I can not stress this enough. That is pretty much all there is to it.

If core team / key members only interact in Slack people will stay in Slack regardless of best wishes, plans, categories on Discourse and 1000 shiny features.

So, the first thing I would worry about is getting buy-in from the rest of core / key members.

Some ideas of increasing involvement here could be:

• What if @tomdale or @wycats did a random AMA here?

• What if some “larger” not exactly an RFC but something that needs complex discussion went here for open discussion by core?

• Can/should core make use of private categories to discuss particular things they need to that are too early to bring up in the wider format.

Another trick that I use on Twitter and Chat quite often is:

Wait a moment I really want to answer it but do you mind asking on [insert discourse site]

I find interrupting the flow is very powerful so that definitely a tool you should consider. I will do this multiple times a week in our chat.

[system]

I’m going to be writing a blog post to clarify our stance on the whole “Discourse (forum) and Slack (chat)” conundrum.

This is now done:

Effectively using Discourse together with group chat

[Hummingbird]

Just another .02$: I do think that it is really difficult to generalise the question, because different types of questions are more or less suitable for a specific medium.

The ember community to me is an awesome community, if you know all the places where you will find specific information because all the resources are scattered around a lot of places. Some go stale quicker than others.

the places you currently need to know to make the most of ember (and there still are things I don’t know where to find):

• emberjs documentation - pretty much a no brainer
• emberjs blog to follow up on past and future changes
• ember learning & guides - best practices
• GitHub to find out if the error you are seeing already is known
• RFCs to follow up on changes that are currently under development
• this forum - for questions, issues and best practices
• stackoverflow - same same
• slack - for obvious reasons
• various great blogs about ember (mostly best practices) - pretty much scattered around the web
• ember weekly - to get notified about interesting add ons (lists good blogs posts and videos as well)
• emberobserver / npmjs et al - more addons
• ember times - best practices and news

If anyone doubts this, I propose to answer the following question: “what was the current status of ember 3.1.0 on any day between 3/26 and 4/10 other than ‘not yet available’?”

I see a number of types of questions:

I am running ember x.x.x and now I am suddenly seeing error xyz and I am totally stuck

Should I open an issue on github? should I ask on slack? should I post here? do I use stack overflow?

It is not very easy especially for new devs to figure out what the right thing is to do. But it actually kind of is:

• is it specific to your code or a general, replicable, framework issue? general issues should most likely end up on github, however the path until they get there is not clear.
• the more specific an issue is to application code, the better it might be suited for real time messaging, as it might take several iterations to collect all the necessary information about the problem. vice versa, the more an issue is related to the framework or a specific version, the better it is suited for a forum or issue tracker, as a number of people most likely will run into it. The easier it is to find out where to search, the less noise everybody will suffer. I remember the last time I accidentally noticed an issue I was having was currently asked about on slack, and people already were that stressed that the only answer has been “the error already contains the answer”.
• Probably we should have more detailed guidelines about which type of question is appropriate for which medium and what the needed details are

I want to build xyz, but I don’t really know if I should do it this way or that way. What is the right way (best practices) to do xyz with ember?

As an opinionated framework we probably should not have this issue as much as the less opinionated ones. However, in the past it often has been difficult to find out how to do it the “ember way”. And this has reached a point where I received an issue for an ember addon, which basically said: ‘you are not doing it the ember way. you should change that’. And no one (not even the submitter) was able to explain what the right “ember way” was. To some degree this is a natural thing, as things evolve and take time to get accepted. However, within the last year I often got the impression that the best way to do things in ember is found on a blog somewhere on the web, rather than on the emberjs website.

I really do like what @rwjblue mentioned regarding the ability to curate parts of a discussion and build a forum post from that. But maybe we could take it a step further and build some sort of moderated emberjs blog. A discussion about a specific question could end with a suggestion to write a post about that on the official ember blog. Someone would take the important parts of the conversation and write a short blog post from that. Before that post goes online one of the moderators would review it and to check if posted information is correct. That way we could end up with a central list of how to do things which is of good quality. Plus everybody gets the chance to appear on the official ember blog. And people with their own blogs could link or repost.

I have a very specific architectural problem that I don’t know how to solve and I need some opinions. Or I need to find out how to build this addon or anything else framework development specific

I believe this is where real time communication like slack really shines as feedback cycles are very short.

However, there is one huge advantage which slack currently has over this forum. Structure. Everything has it’s own channel. The categories here have improved since I looked last time, but we could probably find ways to refine this further. As already suggested earlier, adding an ember version field could probably also help a lot.

In the end I believe we should not ask if we should move everything from one place or another. But we should have good rules what goes where. And we should try to find ways to consolidate all the information that is available. There is a huge amount of great resources out there. But it is very hard to know all the places where they are, especially if you are new to the ember ecosystem.

[sam]

ember version field

That is a interesting suggestion, perhaps a tag? The tricky thing though is that it requires discipline … lots of it to make sure stuff is tagged right