Personally, I think that the reason for this is not because of #helpdesk but because (maybe ironically) of how well this discourse works. Why would I go to SO when discourse has a better way of categorizing Julia things and more of the Julia community is here?
5 Likes
Here’s an off-the-wall suggestion… use Franklin plus GitHub to make a continuously updated tutorial.julialang.org which is a user’s guide with lots of template examples. Frame helpdesk as making tickets to improve the tutorial. This has several advantages, first, there’s a concrete working artifact that one is building (ideally that can have regression tests). Second, there’s an implied request that new users read the tutorial… and frame their question as something not asked by the tutorial. Third, there are outstanding tickets, that can be closed, tracking questions.
The hard part isn’t the answer; but ensuring the answer is findable and remains correct. In this regard Slack channel is the absolute worst place since good answers disappear, they can’t even be referenced.
1 Like
Just to echo some of the things that @logankilpatrick is saying: two weeks ago I gave a “Julia evangelism” talk, and more than one person mentioned that the biggest problem with Julia is that the StackOverflow community is too tiny to be useful. I’m not sure I fully agree, but FWIW another participant in the conversation said “yeah, the real problem is that everyone goes to the Julia Slack channel, and all the good advice there just disappears.” At that point, nearly everyone in the conversation who already knew something about Julia nodded.
I was not one of the ones who consulted with @logankilpatrick, but on the basis of that experience alone I wholeheartedly endorse this change. It’s insane to have good advice disappear, and getting it “out there” in a more enduring and searchable form is just one way that all of us can contribute. As more people use Julia and write cool packages, we’ll all benefit in exchange for the tiny extra inconvenience.
27 Likes
I think it is a pipe dream that shutting down #helpdesk will suddenly boost SO by a lot.
Firstly, SO type of questions tend to be asked on discourse anyway (discourse is the biggest competitor to SO, not #helpdeks).
Secondly, people will just go to Zulip where the community there has already said that they have a #helpdesk channel that will not be closed.
Thirdly, the speed and quality of the help you get on SO is already very good. I tried to be active on SO to answer questions but it was very hard to even find questions that were unanswered (<3 Bogumił and Przemyslaw).
Fourthly, Slack already has a bunch of other help channels that are slightly more specific than #helpdesk, for example, #data, #arrays, #audodiff, #documentation, #gpu etc. Sum up all of those and it likely blows #helpdesk out of the water in activity.
Fifthly, SO is a quite nasty place in general to actually ask questions (it is nice to read answers for though), people downvote you, say that your question sucks, random people with high “scores” come into the Julia category and close / lock the questions etc. I don’t see why we should promote that over e.g. discourse where we have nice moderators and a friendly community.
23 Likes
I really don’t understand the critics about Julia tag in StackOverflow, it has a remarkably low fraction of unanswered questions, 14.7% as of this writing. For comparison, among the top 20 tags, only [c++], [arrays] and [c] come close with 19.5%, 18.2% and 16.8%, all others float around 25-35% of unanswered questions. This means that if someone does ask a question, it’s more likely they get an answer if it’s about Julia than any of the most popular languages. I feel like all people that complain about Julia on StackOverflow don’t want to ask questions and expect to find already the answers.
One can claim that this works only because of the relatively small number of questions, and that may be true (unless we can clone Bogumił and Przemyslaw), but even for tags with about the same volume of questions as Julia, the [julia] tag has still a very low fraction of unanswered questions.
17 Likes
How about a julia points bounty for posting good questions that come up in chat platforms to stack overflow?
On slack/Zulip…
User: how can I do X?
Answerer: Do Y
Community pirate: Great question and answer. If you post it to stack overflow, you can collect a bounty. Just submit the link of the completed post to julialang.org/bounty
Community mod goes through submitted links periodically and assigns user points
User wears points proudly somehow… maybe a leaderboard on julialang.org?
2 Likes
I see a pretty heavy divide here.
Ideas:
- Zulip has a learning curve. People learning Julia may get frustrated to find they now need to learn a new chat tool to get help(or go to discourse)
- Closing Helpdesk might not actually do anything? People will now post their questions in #General or wherever else?
- It is crazy to have the Slack history delete everything from an efficiency point of view, but also somewhat liberating. IE: there’s no record lasting until the apocalypse of someone asking a “dumb” question.
Conclusions - It seems like the “best” solution is to either create a tool or find a tool that allows questions to be cached. Imagine a little button that a question asker could press to create a discourse thread or some other more permanent medium(slack wouldn’t allow this). Maybe the 80/20 answer is Zulip?
- StackOverflow is nice - but it’s a little rough when the syntax has changed so much. At the expense of more knowledge SO is often far more concise than a discourse thread. Often the most upvoted answers do not apply to Julia > 1.0. A community-driven cleanup could be in order(upvote stuff that works in Julia 1, reanswer questions that predate Julia 1.0)?
So far, all the people I consider Julia stewards who actually use Slack regularly, e.g. Stefan, Kristoffer, Frederick, etc, have all come out with unfavorable opinions about this move so whoever made this decision, did so as a Slack outsider. Let Slack be Slack, let Zulip be Zulip, let Discourse be Discourse and let SO be SO. For some decision like this coming from the top that goes against the community that actually uses the tool seems ill advised (and a worrying pattern that feels to me like leading to a PR disaster).
If some influential people in the Julia community want more people to use Discourse or SO, I say they should lead by going there themselves so that more will follow rather than create barriers where things were not broken.
3 Likes
I just want to point out that neither me, nor Kristoffer, are Julia Stewards (I don’t think that is what you meant, but just want to be clear since that is usually what the terms is used for). I do agree, however, that it is strange that this decision comes from people that are (from what I have seen) completely inactive, or at least invisible, on both Slack and on Discourse.
7 Likes
In fact I think the julia SO is pretty incredible in terms of response time. I gave up earning SO points on Julia like a year ago, because the time window from a question is posed to it has a high-quality answer was simply to small for me to ever get an answer in 
FWIW the quick response on the Julia Slack helpdesk on minor non-SO’able questions is a major component in maintaining my productivity in the language at all.
13 Likes
One theme I’ve noticed is that people are mentioned that “quick” questions are for Slack and “detailed” questions are for Discourse. Perhaps that disconnect is part of the hesitancy toward this decision. I might submit this to the #confessions Slack channel, but probably 50% of my Discourse searches involve silly things I just forget like “how do I add leading zeros?” To many this may be a “Slack” question, which will be answered fast, but is inevitably lost. And I don’t see myself or others talking the time to manually cross-post once an answer has been found. In Slack, questions can be repeated ad nauseum, especially as the community grows.
To me, a relative outsider, Slack/Zulip still feels like a bit of an “original users club”, for lack of a better term. I recognize many of the names posting here, which means we aren’t hearing from new users, the ones #helpdesk is purportedly helping the most. While I definitely see the value in the Slack back and forth, I do think it’s worth it to encourage Discourse over Slack/Zulip rather than have them on equal footing. Also, I see lots of examples and help in the #plotting channel go down the drain instead of being archived as cool examples of the possibilities on Discourse.
Before I ramble on much more, my original point, maybe we all just need to change our frame of mind, Discourse isn’t for a “certain type” of question, but it is indeed for ALL questions regardless of complexity. I know I have started asking more questions on Slack/Zulip of late. But having given this some thought, I do think I will try to only ask questions on Discourse in the future. Maybe some other user(s) can benefit from my ignorance.
13 Likes
Out of curiosity, how do other programming language communities handle the divide between Stack Overflow and their language-specific Discourse?
For example, the Rust community has a Discourse. Actually they have two: one for usage and one for internals. The “usage” Discourse is where helpdesk/Q&A questions go.
But also there is the [rust] tag on Stack Overflow.
So, how does the Rust community handle this dichotomy?
And how do other programming language communities handle it?
Perhaps there are some lessons that we can learn from the experiences of other communities in this regard?
Edit: maybe one of the Julia community leaders could reach out to some of the community leaders in other programming language communities (Rust, etc.) to hear their first-hand perspectives on this issue?
4 Likes
Answers should be useful. Email chains like those for old Stata / Postgres and many other communities are all preserved / “indexable” / persistent and a total headache. Some time ago there was a push for good answers to be copied over to the Discourse for increasing that benefit. I think that’s fine but I really really enjoy the quick turnaround dynamic of asking on Slack. I am on the Postgres and Selenium Slack workspaces and they do decent job but the Julia workspace is far better at it. I don’t know how the discussion happened this time but I don’t remember seeing it referred on Slack until after the deadline and I am on the Slack literally all the time (I check Discourse daily). In summary, I think shutting down office hours (quick Q&A) to “force” folks to go through a formal Q&A documented process might not be the right approach.
3 Likes
Discourse has an API.
Since we self-host our Discourse instance, we should have access to the Discourse API. EDIT: We do not self-host Discourse. However, we will most likely still be able to get access to the Discourse API.
The Discourse API is documented here: https://docs.discourse.org
I’m not sure whether or not there are APIs for Slack and StackOverflow to which we will have access.
1 Like
A question for clarification:
You worded most of your statements in plural, for example
Who are this “we”?
I completely agree that the community is doing amazing work. Like I said in my post, I don’t entirely agree with the statement. But just for context: the number of questions tagged as:
-
[julia]: 7,415 -
[rust]: 18,520 -
[python]: 1,550,587
I suspect that’s the number which is driving this perspective, not any statement about “helpfulness” or “quality.” It’s probably the people who aren’t actually asking the question, just searching for it, that care about this.
But I certainly don’t see any reason to promote SO over discourse. I agree that discourse is much nicer overall.
10 Likes
I think rather than “just” about SO, it’s more of a:
Increases the visibility of Julia as a language (in language rankings and search results)
which Discourse will also do just fine. But Slack will contribute exactly 0 to this. My personal feeling is given the activity and helpfulness of our community, we can probably rank higher (which hopefully will create a positive feedback loop).
2 Likes
Thanks everyone for the thoughtful feedback and comments. We will hold off on closing Helpdesk (I’ll update the title above to reflect this so as not to confuse folks reading this in the future).
However, the core issue of scalability still remains. If you are interested in working on this issue, feel free to get in touch with me as this problem will need to be addressed at some point.
37 Likes
Thanks for taking the responses to heart and giving this some more though. Since I can see both sides of the argument, I hope we can find a solution everyone’s happy with before running into real problems 
5 Likes
it will be nice to have an infobot that you can teach knowledge and store them. since slack is a modern version of irc help channel, the typical approach of interactive troubleshooting is to summarize the solution in a knowledge database by using an ircbot-like system. troubleshooting is a bottom-up approach but once you figure out the solution, it’s good to create a top-down description of the solution. it can be brief most of the time but it’s important that we can easily recall it back. typical interaction in irc help which is effective will be:
/msg juliabot listkeys to search the keys part of the factoids
/msg juliabot listvals to search within the values of all factoids
/tell username about factoid “vectorization in julia”
/teach juliaboot about “testing in julia” is <REPLY> testing is …
whoever figured out the problem or posed the problem and got the solution is expected to do the summarization. without the summary, searching the bottom-up interaction until arriving at a solution takes time. it will be faster if you can search the top-down summary of the solution.
this infobot knowledgebase can be stored in the cloud and shared across different platforms (zulip, slack, discourse, SO).
1 Like