Brilliant! Looking forward to seeing how this will help the community. 
1 Like
Course of action: I plan to enable this sometime tonight, after sending proper notification, and mention the ability to stop a re-post. Please ping me here or on slack if there’s other feedback around this.
4 Likes
Let the bridging commence! #helpdesk-bridged
3 Likes
I just had the honor of creating the first bridged post 
What’s the update frequency of the bridged category here on discourse?
1 Like
BTW, is it expected that I see a “Sorry, this section is only for Bots.” banner at the top of the #helpdesk-bridged category page?
2 Likes
Ooops, I was messing with something and it broke it. Should be good now. Go post a quick question to keep your place in history
Also, can you post a picture of that message?
The bridging message “consider answering the question there” could imply that one should answer only in Slack, whereas it seems preferable to always answer here for posterity. So I’d like to suggest rewording the bridge message to something like this (see emphasis):
Note that the original poster on Slack cannot see your response here on Discourse. Consider transcribing the appropriate answer back to Slack, or pinging the poster here on Discourse so they can follow this thread.
The current message:
Note that the poster on Slack cannot see your response here on Discourse. Consider answering the question there or pinging the poster here on Discourse so they see the response.
3 Likes
Updated!
1 Like
Just saw this post come through, and the && in slack was replaced with && in the discourse post. I just edited it, but there, but that’s gonna get old fast.
I have an issue open for this and am looking into it: Formatting issue when the message from Slack includes special characters · Issue #8 · JuliaCommunity/SlackBridge · GitHub
1 Like
So there’s a rather long winded discussion thread currently on Slack about this bridgebot, and I’d like to just copy over a couple points I made there to here for posterity.
I think that the Bridge-Bot is creating a flood of noisy, unhelpful, low quality posts on this Discourse that have a very low likelihood of being useful to future people. With most of these posts, if they were created by a human, the first response would be to link to Please read: make it easier to help you because the post does not meet the sort of quality expectations that this Discourse community has.
One major problem is the titles. If any of these threads appeared in your search results when looking for something, it’d almost never be obvious if the thread contained any useful information:
But I think beyond that, a very large number of these threads never get responded to on Discourse, and after a couple of weeks, the thread is lost on Slack, so we end up with a bunch of threads that’ll pile up that just consist of a unhelpful title, a vague question and no answer. Personally, I find that Discourse’s search functionality is already really unhelpful and I worry about these posts further cluttering search results and making it harder to find valuable information.
I think at minimum, we should be automatically deleting bridged threads older than two weeks that were never responded to.
More broadly though, I still worry about the idea of shoehorning Slack posts into Discourse because of the huge cultural differences between the two communities on what is considered to be a valid, or acceptably asked question
17 Likes
One possible solution that might fix a few problems:
Instead of replying to a post in a thread, the bot can Direct Message the author with a more verbose message. The key point of this will ask them to potentially edit this original message with more details so folks on discourse can help easier, etc.
This also helps address concerns by @JeffreySarnoff such that when you look at helpdesk you don’t see a bunch of bot messages.
Thoughts?
I think the bot’s visibility is not the real problem - if a user posts a clear, carefully-crafted question and is immediately answered by a bot who implies that their post might lack detail, that’s bad whether it happens in public or in DMs. Look at MS Word’s Clippy or impenetrable call center keypad menus: few people enjoy answering a robot’s questions. Better to inform users how to summon the bot if they want its services.
2 Likes
Instead of replying to a post in a thread, the bot can Direct Message the author with a more verbose message. The key point of this will ask them to potentially edit this original message with more details so folks on discourse can help easier, etc.
Thank you @logankilpatrick for doing the heavy lifting on this. We share this desire to provide helpful help set comfortably while providing the Community a more refined accretion of accessible expertise and operational wisdom.
To have a more nuanced message and to provide that message to the new questioner is sensible. To repeat that action every time that questioner asks other questions (understanding that participants tend to ask questions in bunches – while involved with that which brings the questions to light) is heavy-handed and increasingly obtrusive unless individuals have an easy way to whisper “stop, please, I know this” to the automated process.
If “direct email” is used, please take advantage of the collective us to assist in getting the message tonality and the messaged expressiveness right, along with providing correct and helpful guidance. It would elevate the overall effort to have a thread participant decide the content belongs vouchsafed to discord. That requires a very stable and simple "button or readily accessible bot rouser that performs the task after allowing that human to provide a new, more transparent phrasing of the question and to select a few keywords that make the content easer to find.
3 Likes
With respect, and appreciation of all the work that went into implementing this bridge, I would propose that it is just discontinued. It was an interesting experiment with good intentions, but I don’t think it is working out.
I think that @Mason phrased it well: there are cultural differences between the two communities. Automating cross-posting may not be warranted in this case.
FWIW, I decreased my involvement on Discourse because the noise just got to be too much.
13 Likes
I agree with Tamas, it’s better to discontinue this experiment. There is nothing wrong in negative outcome, in the end of the day that’s what experiments are for. But sunk cost fallacy better to be avoided.
5 Likes
The ideal situation seems to be the following:
- A user writes a nice descriptive question (that has the possibility of a good answer) in #helpdesk in Slack.
- The user gets the answer on Slack, typically over a set of chat messages.
- After getting an answer on Slack, the user summarizes the answer nicely and posts it to the bridged discourse post.
- There is now a permanent record of a nice question with a nice answer, something akin to a stackoverflow question.
- When someone googles the question, they will find the Discourse thread.
Now, does this happen in practice? From looking through the bridged category (and having these bridged posts show up on the discourse front page all the time), I would say no. What seems to happen in practice:
- Since Slack is a chat, the original question is often low-effort and the details of the question will usually come out after some back and forth in the Slack thread. This is not reflected in the Discourse bridge post.
- Many questions are double answered (Slack and Discourse), causing extra effort by the community.
- The author of the question almost never replies to the bridged discourse post with the answer he/she got in Slack.
- The type of questions are not really those that you care to achieve anyway, often the user just wants to have some discussion and it isn’t a “stackoverflow type of question”. An example is “Does anyone have experience with saving/loading arrays with
JuliaDBandDagger”.
To me, the bottom line is that a chat and forum are two different kinds of medium and they have different cultures in how you are expected to behave. In particular, on Discourse the culture is to have quite well-written questions, provide MWEs etc. In Slack, it is a more laid-back and free-flowing type of communication. Cross-posting Slack type of communication onto Discourse makes it come off as low-effort and almost rude. There is not a problem with the Slack communication itself, it was just forced onto a place where it wasn’t intended.
The net result feels to me that the #helpdesk in Slack is noisier with the bot messages and Discourse is noisier with all the perceived low effort questions. And the tangible benefit for this is very low if any. Neither do I see a good way of fixing it with some small tweaks. So personally, I think it was a good experiment but I don’t see much reason to continue it further.
23 Likes
I agree with Tamas and Kristoffer. I also feel like the only thing the bot achieves at the moment is extra noise on both Slack and Discord.
Discourse lets you mute categories completely. I muted the bridged category after a day or two and since then I have not seen any of the posts. (This is not a solution to the noise problem since the noise is visible by default and also show up in e.g. search engines, but it is an effective remedy for the current situation).
9 Likes
Back when there was discussion about closing the #helpdesk channels, I made a point about trying to encourage users to post their questions to Discourse first. I still find occasionally that answers to basic questions that have likely (though not definitely) been asked on Slack/Zulip are not present on Discourse.
If we think from a beginner’s perspective, then they will most likely do an internet search for their question first before asking it themselves. I think it would benefit the beginner community more if somewhere there was a stated preference encouraging people to ask questions on Discourse first, and then only if the topic goes unanswered, go to Slack/Zulip to say “could anyone help me with my discourse post?”.
4 Likes