Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Bot to steer discussions from Slack to Discourse (dgraph.io)
106 points by mrjn on June 15, 2016 | hide | past | favorite | 47 comments



Wow until about half way through the article I read Discourse as Discord, and it didn't make any sense to me. Now that I understand, this seems like a pretty cool solution. I have been really loving both slack and discord for personal use. Unfortunately, my work use Skype for business. I have been pushing for a switch to slack.


I read exactly the same thing - I was wondering if he was going to start touting how amazing it is to be able to just start talking with people in "Engineering Rooms" or something.


The naming similarity is unfortunate, but they are both great English words that more or less accurately describe the respective products...


> Discourse has become such an integral part of our company that we abandoned making decisions in meetings entirely.

That's really impressive and cool.

Being an old Usenet fart, I have some problems with Discoure's linear discussion threads (I don't have that problem with twitter's similar structure though).

But I guess if you can keep people on topic and open up new threads for discussions that get side-tracked, it can be a really cool tool.


Have the Discourse developers ever commented on whether they deliberately didn't support visualization of the thread structure? The software appears to know the thread structure (because there's a specific UI to reply to, and quote, a particular message), but it doesn't do much to show it to a reader -- or provide other thread features that you might find in a news reader, like marking a subthread as read or hiding it.

Do we know if this is something Discourse might support in a future version?



I have read this piece before but I mostly disagree.

"Putting aside Usenet as a relic and artifact of the past, [...]"

I think this is a crucial sentence for the whole post. He brushes aside the probably best example for a threading model. He never asks the questions "why did it work on Usenet?", "why didn't/doesn't it work on the browser?", and "could we make it work in the browser?".

Most of his arguments concern wrong UI designs for a threaded model. For example "you are talking to everyone". The argument that the reply button leads people to reply to the wrong message is completely refuted by reddit. It's just that the location of the reply button has to be carefully chosen and on reddit they have done it right. There's one reply button for the thread and one on every message.

I usually can accept opinionated design decisions but in the case of discourse, they implemented a half-assed solution. You can expand replies in discussions but then you can't drill down and expand the replies to those replies.


The continued success of Reddit (basically wiping out flat by default web forums) and the fact that Facebook has at some point between then and now introduced threading seem to prove it isn't too complex for most users. Only the old vBulletin pagination + threading model was.


Meanwhile you can't have deep discussion on Reddit or HN. When a new submission is made, the peanut gallery storms the top-level. Then a little bit of discussion nests a few levels, but it's pretty much a one-on-one discussion due to the nesting. And since topics can't be bumped, the discussion is ephemeral. And if you have something to say on a topic that's more than 24 hours old, then only the person you're replying to will see it.

Traditional forums have other issues, but longform discussion among multiple people over periods of time is possible.


I feel exactly the opposite. Traditional, non-nested, forums with more than a few users end up with many pages of @author comments that make it difficult to track the course of the conversation. With nested comments I know exactly who someone is replying to and the topic they're discussing. I think the issues you're pointing out (top-level peanut gallery, no bumping, >24 hours old) are more problems with news-driven websites than nesting vs non-nesting. If you had a reddit-style nested private niche-topic forum the pace would be slower and the problems you point out would probably be less of an issue.


The tree structure is pretty useless and incomplete on a traditional forum. The only information you have is when the user explicitly opts in to a quote-reply.

Most replies are written in the quick-reply box (no parent) because they are responding to what is being said in the last X posts. Assuming orphan posts are top-level replies to the topic is nonsensical, and you can verify this by toggling on threaded-view on forums that support it.

The next best thing is to just link the upstream post from a post that quoted/replied to another, which is what Discourse and traditional forums already do.


Of all sites, I have found all the disparate sbnation sites to have the best live, threaded discussion model. They do it threaded like reddit or HN, but new updates show live and unread and there are various shortcuts to jump to next unread, mark all as read, etc. The key to live, threaded discussion is unread message support.


> The key to live, threaded discussion is unread message support.

Exactly. The issue that many discussions on Reddit turn into one-on-one discussion is because of this. You can easily see new replies to your comments but not for other new comments.

The HN has the same issue but it doesn't seem to be so extreme. Maybe many people have site enhancements scripts installed? There are various browser addons for Reddit that highlight new comments since the last visit but it would of course be much better, if this were a standard feature.


Sounds like it's working for you. Why people don't turn notifications off is beyond me though. Still, curating/making asynchronous is the biggest issue with slack so thumbs up.


The main reason for not turning off notifications is the fear of missing out, decisions being made without you. And it's a very valid fear.


You seem to have posted this in multiple places. I don't think it's a valid fear at all. If people are constantly monitoring Slack for fear of missing out on decisions, then don't make decisions over Slack. It's really as simple as that.

We have policies that dictate what types of conversations belong in Slack and what types of conversations don't. If something requires a person's input, they are summoned to Slack via a mention. Otherwise, it's widely understood and accepted that Slack is primarily for Q&A, collaboration, sharing of cool finds, and what we classify as "general chat."

Other than that, we also have meetings (both in person and via remote session/conference) for more important topics and decisions. The results of those meetings are communicated to the team via email (which everyone is expected to check twice per day).

If you try to use Slack for everything, it will fail for you. That holds true for any tool.


Agree. In fact, that's the main motivation behind this bot is to ensure that we don't use Slack for everything.

But, it goes beyond that. We also realized that Slack wasn't a productivity enhancer, it was a bonding catalyst. And realizing that helped us steer conversations away from Slack.

In other words, Slack for us is the equivalent of what would be considered water cooler talk.


I recently had to deal with some Discourse users trying to hijack my community's discussions to a Discourse chatroom. Absolutely awful experience and terrible client support.


Almost certainly referring to Discord, as Discourse doesn't have chat. Not that people haven't asked us to build it, but I think a good Slack integration is a far better choice, plus Slack is free (in terms of hosting costs, and ease of starting with just 2 or 3 people) in a way that is highly complimentary to what Discourse does.

I like to think of Discourse as the "long term memories" in Pixar's Inside Out. You ship stuff there as you need to. A mixture of mostly short term and sometimes long term memories is a sane and manageable arrangement for most humans.


Could you provide more details on what happened? It sounds like you have a mix of human issues, "users thing to hijack" and something with the product "terrible client support".

I'd be interested to understand what you ran into in more detail.


Are you talking about Discord?


It seems that I am. I even read the blog post thinking it was about Discord. Apologies.


Instead of going through contortions trying to break bad Slack habits and worrying about the API getting shut off, maybe it's worth checking out something made for the purpose.

In the original post from the AgileBits team quoted at the top, that team tried Basecamp, which to me seems to do a good job of separating thoughtful/long-form discussion from chat, along with the weekend-pause feature.


Very excited about this! We're on the same path of Slack+ Discourse. We tried switching chat to other tools that would be more fit for purpose but just couldn't drive engagement. Slack is too sticky.

I'm planning to take this bot for a spin today. Aside from that, it's just great to hear there are other companies feeling the same pains as we are.


Awesome! We took that detour as well, tried a bunch of other chat apps, but in the end, Slack won out. It's the most mature chat system out there.

With Wisemonk keeping us accountable, we're now able to tackle the negatives of Slack; so eager to learn your experiences.


Or just turn off notifications on every message? I only get notified on @mentions and I don't feel like I'm oncall.


The main reason for not turning off notifications is the fear of missing out, decisions being made without you. And it's a very valid fear.

One team member going away from Slack is bad for the member and for the team. If everyone else participates and you're on the sideline, then you're an oddball and not a team player.

For it to be effective, the whole team has to willingly move away from it.


Do you all work at companies that don't do design reviews and code reviews? Those seem like good ways to keep people in the loop and get feedback on idea/code. Code reviews should be interrupts, but nothing else should be.

I find the amount of work one can practically achieve in a day to be a good limiter of how much people will be kept out of the loop if they are not actively engaging in their email (or whatever system people use). The reality is, no matter how fast you think you're moving, it's not that fast.


We do pretty strict code reviews https://github.com/dgraph-io/dgraph/pulls?utf8=%E2%9C%93&q=i... . Nothing goes into master until it gets LGTMed.

The point was that, if all of your team members are having a conversation, but you're not, you'd feel left out. Of course, you might not care, but a lot of people who feel they're active part of the team do; and discourse allows us to do that very well.


I agree, this seems very much like a culture problem that wants a culture fix, not a technical one.


Not too familiar with Discourse, and I'm curious about the difference to trello comments on a card (in this context of taking discussions offline from slack.)

Could anyone who uses both trello and discourse care to comment about the difference in experience?


We at Dgraph use Trello as well. TBH, the commenting on Trello is primitive compared to Discourse. We still comment on Trello when we're talking about specific cards -- but if it needs thorough discussion, we always go to Discourse.

In fact, it's pretty common for us to create Trello cards out of discussion at discuss.dgraph.io.

Also note that we keep our Slack only for general chit chat. As soon as something becomes more "structured", we switch it to Discourse. We also actively encourage people to just create topics there instead of bringing it on Slack in the first place.


Huh, I can only assume slack is going to remove this api very soon after this, nothing makes companies clamp down on openess sooner then syphoning off users.


I was going to say that's unlikely since the API is part of what makes Slack Slack, but I would have said the same thing about Twitter 6 years ago...

That said, Twitter and Slack are very different beasts. There is not nearly the same network effect to keep teams from switching to a competitor... except to the extent that 3rd party products integrate with Slack's API...


I do not think that this particular extension will have enough impact on Slack for them to feel threatened.


That's fine.

Their potential killing of the APIs won't affect if I use Sikuli to automate it.


A letter from a lawyer might though


Perhaps true. But Sikuli automates the keyboard, mouse, and the screen using OpenCV/Tesseract for object and OCR detection and programming logic.

The only way you'd be able to detect that is by measuring the amount of ms between clicks. And that's defeatable by adding in a random range of 0-300 ms per click. And send the data to a private IRC room. Node-Red can easily handle the data from there.

Now, it looks just like a human.


Shouldn't developers have the freedom to create whatever they like with "open" APIs made available?


Open API's are basically, have others keep trying ideas until one sticks, then we'll consume the project and roll it up into our product.


Absolutely they should. But I don't think a rational self-interested company would continue to allow those APIs to be used in order to facilitate a competitor siphoning off users.


I think a completely rational company should try to understand the problem. This is a relatively "known" problem with Slack and other realtime chat (i.e. the timesink issue). It's one reason I'm always cautious every time someone at work gets excited about "soon we'll have Slack!!!" based on experiences at my last employer where it sucked up productivity like a black hole.

I've seen a growing number of people actively moving away from Slack or complaining about it due to these issues. How can Slack fix that? Close off an API to stop hiving off users? Well the explicit intent of this approach is to use both tools so it doesn't seem like they lose much.

Either way; I'd argue that a rational company would look at why it's customers were doing these things and then either a) add that feature to the product or b) let things alone.

Slightly different if it's an "export your Slack chat to A.N.Competitor".


Right on, I approve of this. I wish people would give up on slack already - it's a proprietary hype machine that's made it's way to the core of too many complex systems.


So, do you have any real criticism or do you just hate proprietary software and hyped things?


For FOSS advocates, the proprietary nature is the criticism, as proprietary software has been shown time and time again to be harmful to users.


>>as proprietary software has been shown time and time again to be harmful to users.

A bold claim that requires quite a bit of evidence, in addition to evidence that the alternative (FOSS) is not harmful.


It is the core thesis of FOSS. https://www.gnu.org/philosophy/free-sw.en.html




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: