Often referred to as religious wars. No one is going to change anyone else’s mind.
1 Like
Julia-bashing posts, which bear prejudicial and gratuitous attacks on a very successful open-source computing project.
There should be a NLP model implemented in Julia to do this.
2 Likes
Colloquially known as don’t feed the trolls.
Also important not take any constructive criticism as “stupid”. I know that’s not what you mean. But just commenting.
Having myself been hooked more often than I’d like to admit by these posts, some kind of nudge to not feed the trolls would definitely help. I missed the latest bruhaha while it was happening, and at several points wanted to respond, but couldn’t. I’m the end though, it was a bit of a relief to not have the option.
I don’t have a strong opinion on what policies would be good for the forum overall, but a post from a steward flagging a post as possible flamebait (I do think a more diplomatic phrase is warranted) would go a long way to helping me personally.
I’ll also happily help with a wiki 
7 Likes
Now I cannot help wondering how many users are actually sock puppet accounts of trolls from the python community.
We have no reason to suppose this phenomenon is widespread, or accuse the Python community in general of any bad practices. Let’s not go there.
I agree with this, but at this stage of Julia’s development it takes quite a bit of effort (and using Julia for a few months) to suggest anything that is constructive, but not yet known in an issue.
11 Likes
For a bit of light relief, I cn’t help but link yesterday’s SMBC comic.
16 Likes
I think the great thing about stackoverflow is the fact that the scope of the website is narrow and rules about what is accepted very specific. When your policy is “no question that doesn’t have a provable and technical answer” it naturally shuts down most possible problematic posts. But here what would be the policy? Flag all posts that have the potential of igniting a flame war (I propose the term “potential ignitor” for them 
)? That’s unspecific at best.
Another thing from stackoverflow that may be of interest here is the “discussion moved to chat” feature. Moving fast moving and heating discussion to somewhere more discrete and lower traffic may help keeping the main thread chill without explicitly blocking discussion or silencing anyone, as long as the discussion is clearly linked from the main thread.
3 Likes
This description makes me wonder whether the default display method is a contributing factor. Currently, the default behavior is to sort threads according to the most recent reply. Displaying the thread with the most recent reply at the top creates a positive feedback loop in which a topic “sticks” to the top causing it to attract even more responses. I wonder whether moderators can change the default display to something along the lines of “most recent with 0 to n replies” where n is a small number and recent is a small number of hours.
2 Likes
I haven’t read most of this, but I don’t think being aggressive about tagging things as flamebait will go well — then we’ll just end up in meta arguments about whether things are flamebait or not.
I do agree that it’s getting tiresome to have these periodic big threads with this general shape:
- new person shows up and gives a bunch of feedback, both positive and negative
- lots of people reply, both agreeing and disagreeing
- the sheer amount of discussion is overwhelming and even if no individual bit of feedback is particularly confrontational, the overall pile on effect is
- the conversation wanders off topic and gravitates, naturally, towards contentiousness
Rather than trying to control the content of feedback by labeling it as flamebait, what about attacking the particular shape of problematic discussions instead? The problematic threads are almost always very broad and discuss a lot of different topics. With a lot of different points of feedback in a single thread, even if some of them are positive, there’s always something contentious for the conversation to gravitate towards. It also makes it nearly impossible to shut down the discussion for covering already-well-trod territory since even though individual points of feedback are often repetitive, there are endless combinations of feedback points.
So what I’m inclined to do is to institute a “feedback unbundling” policy: when someone posts one of these threads that lists a bunch of different points of feedback, a moderator can post a standard message saying something like this:
Thank you for the feedback! We have a policy that discussion of feedback should be separated into individual threads of discussion each specific feedback topic. If you or anyone else wants to further discuss one of these points, please feel free to start a new focused thread quoting the relevant portion of this post. Keep in mind, however, that there are many common topics that are already well known to the community and which have been discussed many times before and are actively being worked on. Before starting a discussion thread about one of these common topics, please read through past discussions to avoid rehashing the same conversations.
Then the moderator can lock the thread and link to a wiki post of common topics with links to previous discussions of those topics. This will keep individual threads focused on a single topic, which should hopefully keep them from sprawling (if they wander off topic we can split them), as well as avoiding situations where so many people feel they need to pile on and reply. It will hopefully also cut down on some of the rehashing of well-trod topics by newcomers, which seems like a particularly problematic dynamic since newcomers may not realize that pointing out that it takes a long time to get to a plot from starting a fresh REPL is not a novel observation, not especially helpful to point out, and likely to irritate people who have seen these discussions over and over again.
27 Likes
I wonder if it would be possible to run some analysis on the post before it appears in the thread and alert the OP to topics that have already been covered thoroughly in the forum? I know that something like this already appears on the right of the submission box, but if it was mining the text of the post for a variety of topics, perhaps that information could prevent posts that rehash old topics over and over again.
1 Like
We use a similar approach in some of the exercism repos that see a lot of “why don’t you just do X” issues. If someone who hasn’t posted to discussion repos before opens an issue, an automated response points them to https://github.com/exercism/docs/blob/main/contributing/chestertons-fence.md which contains tips on how to rephrase the suggestion or topic, why these kinds of discussions can be problematic, and finally an example of such a topic.
One potential problem with this approach is that it may feel rather unwelcoming. I think it’s important that the message outlines the reasons behind the policy and contains some prompts to actively check and improve the original message of the thread. Otherwise it may just leave the OP discouraged from posting again even when they have actually valuable feedback
3 Likes
You have a more optimistic opinion of the state of the art of NLP than I do 
5 Likes
Definitely worth trying. Let’s see what happens.
1 Like
As a passive outsider I think it could be helpful to have a very visible ‘Julia Wishlist/Goals’ that people can +1. Outside of the Github, just very simple. Any forum poster can then be invited to create or vote on it, so they feel heard. Each one could then link to the github issues or a forum post.
The problem of untangling the information in a forum has always bugged me too. I wish replies to a specific topic spawned a new column within in a single forum-thread 
Massively-parallel flamebait if you will.
I echo the sentiment that the Stack Overflow approach of tagging and redirecting suggestions/complaints can seem a bit bureaucratic. The feeling of a community is important. So far this forum has had a very helpful and welcoming atmosphere.
13 Likes
Maybe having a “frequently reported gripes” locked and pinned topic with a frank and short discussion of what people frequently wished Julia had and what are the plans to address it (periodically updated) would go a long way towards defusing this kind of post, and would be very useful both to beginners and experienced coders. The julia community naturally has a tendency to focus on the good, which makes people want to fill the gap and point out what’s bad.
9 Likes
While Julia is not perfect, at this stage it is mature enough that even discovering areas that should be improved requires some immersion into the language (and then frequently the solution to these problems can be something else than even experienced core devs expected a priori — eg cf the recent latency improvements).
Most of the issues new users run into are just about Julia being different compared to what they are used to. Usually it is different for a reason, and until that clicks the user may have to write a few kLOC of Julia.
2 Likes
@mbauman, @StefanKarpinski: would it be possible to agree on convention to signal posts like this to the mods to experiment with unbundling?
If that’s OK with you, I would suggest flagging it as “Something else”, then putting “unbundle” as the reason.
2 Likes
What you see as a particularity of the language that just needs the right frame of mind, a newcomer might see as a fatal design flaw in the language. There are a few common pain points (slow globals, loading times, etc) that are encountered very soon in the julia discovery process, and a common source of (mistaken) “this language is unusable”. Furthermore, there are a few areas (os, real time, scripting…) where julia is just not a natural choice (yet?). We should not answer “it’s not a bug, it’s a feature” but make clear what is part of the fundamentals of the language, what needs a workflow change, a workaround, what is an implementation issue and will be fixed eventually, etc. Such a post could be a good opportunity of doing so.
11 Likes