I know this is a cliche question in this community; however, I feel that Elm should update at least once a year, or at least release minor or beta versions to gain attention from newcomers.
If the language doesn’t receive updates for a year, many people or newcomers might think the language is dead. Even though the language is quite stable, making small changes like updating the version number or anything similar would make the language more interesting, in my opinion.
I wonder if we could moderate posts like these better? I know the concern is genuine and the possibility for misunderstanding is real, but also, this will be the (N+1)th time around this unproductive and emotionally draining loop.
Which would be the best approach:
?
That does seem like it could lead to greater adoption of Elm. However, we don’t control Evan’s process for releases. Elm core is open sourced code, but not open governance. A bunch of Elm community members might agree with you as well, but we’re not in a position to make changes to Elm’s release model.
What about link & not close?
If we link, what do we link to? I think Lore: Elm Core Development has some solid thoughts here. I also think that the person posting (generally speaking) might be one of the lucky 10000 who are learning about this for the first time, so closing/merging/deleting/downvoting might be a bit abrupt.
I honestly don’t think that releasing for the sake of releasing makes much sense. Having a standard reply would be really useful. Having a statement from an official source to link would also be really helpful. This or this might be the closest things we have to an official statement.
I like the idea of linking to existing discussions. But not closing, deleting or downvoting, these actions come across as hostile to newcomers.
Another possibility would be to create an FAQ category, with one post for each such topic, and we could link to those posts (and maybe even link the FAQ category from the pinned post if that’s possible)
On subreddits that have evergreen discussion topics that the community doesn’t want to see continuous new posts for they make a “open thread” pinned to the top of the subreddit and direct discussion to that. It might get refreshed every month so new voices can speak on the issue.
Even if the new voices don’t add any new points to the discussion (as OP here seems to acknowledge is the case for them) I think it’s a good idea to let them speak and preserve their existence. Every new post is an additional data point management might take into account, after all.
That is what I was thinking by “Merge into existing topic” - basically just remove the topic but append the new post to the end of the open perpetual one.
Is there a mechanism for that in Discoure?
Another language that I’ve seen face a lot of similar questions is Clojure. Clojure has a similarly thoughtful and deliberate approach to development as Elm. This tends to provoke similar reactions (for example, do the comments here look familiar?), including periodic “Is Clojure Dead?” posts. I am sure there are more languages in the same boat.
I don’t think token activity will meaningfully change this for Elm. Clojure has more visible activity, and (I would guess) a larger number of online communities (e.g. here or here) that can be found relatively easily, but gets similar questions about its activity.
Unfortunately, I think this suggests there’s no easy fix for these kinds of questions. My sense is that they come from an expectation set by larger languages and frameworks, particularly those in the front-end/javascript ecosystem, which means that smaller language communities have less agency in challenging those assumptions.
Perhaps there are good models for dealing with these questions in forums for other languages?
Welcome @theparitt to the Elm community! Please don’t take @rupert’s answer too harshly. You’re pointing out a real and recurrent issue that we shouldn’t put under the carpet.
I’m not really looking for an easy fix - the question is valid too. What I am looking for is some moderation on the subject, and that requires someone to do some small but annoyingly recurrent amount of work. What work can we do to manage this better and avoid the “unproductive and emotionally draining loop”?
Yes, sorry - that comment wasn’t aimed at anyone. I was more suggesting that it’s not obvious to me what the best course of action is, and that the question isn’t unique to Elm.
I think your suggestion for further moderation is good, positive improvement, for what it’s worth.
I looked at the FAQ for the first time now and it seems more a code of conduct. Although few will read the FAQ before posting, it would be good if it actually brought up frequently asked questions, such as this one. 
I don’t think we can compare clojure and elm situations here.
Clojure gives you much more freedom with how you can use it and aids you with extending it. Elm goes in exactly opposite direction.
Also process for contribution to Clojure is maybe tedious but at least it’s there.
Maybe clojure.spec is very late, but in the meantime community could build and use Malli.
I wrote Lore: Elm Core Development with the help of other community members specifically to be able to answer recurring questions like this one graciously and constructively.
The question asked here is answered under I think Evan/”the core team”/”leadership” should just <some action>, it would <good outcome> for <good arguments> section.
While I and others worked hard to make the whole page relevant, I think the How to progress this dialogue part is probably most relevant for the moderation question.
I’m personally torn on the idea of “public catharsis is healthy” (it sets some complicated & implicit expectations, a discussion in its own right).
But I AFAIK we don’t have active moderation currently, so within the realms of what is in our immediate control, I think “Link and keep open” is our only practical default.
Most of the current discussion centers on one measure of activity in the Elm community: the Elm compiler. But there are other measures, among which is the general creative ferment one sees in new packages (and updates to them) and in new projects and initiatives highlighted in Discourse and in places like Elm Weekly, Elm Radio, and Elm Town.
I hesitate to enumerate specific projects, because for reasons of both space and my own limitations, I can’t mention all the projects that deserve mention. But here are just a few: Gampleman’s elm-visualization, jfmengel’s elm-review, Dillon Kearn’s elm-pages, Ryan Haskell-Glatz’s elm-land, and Mario Rogic’s lamdera. Or, consider the case of Vendr, the billion-dollar company that uses Elm on the frontend.
If one looks at a wider range of indicators of community activity, I believe one gets a much more accurate view of what is happening. And happening it is. The Elm community is small, but full of creative energy. And of course the Elm compiler is what makes this all possible.
Nobody in the wider JS/TS community takes any of that activity seriously, because of the topic of this thread.
+1 for ‘link and keep open’
Starting from the point
Nobody in the wider JS/TS community takes any of that activity seriously because
many people or newcomers might think the language is dead
seems to be putting the cart before the horse. If the goal is to attract more people, then first we need to note what our limitations are, who we want to attract, and then how we might attract them.
We aren’t Evan and have no control over the release cadence of Elm. Therefore anything we do must take that into account.
Being that Elm is statically typed, we likely don’t want to target people who really enjoy working with dynamically typed languages. This eliminates people who consider themselves diehard [JS, Clojure(Script), Ruby, Perl, PHP, etc] developers. These people would likely be frustrated having to deal with making types fit.
Since Elm has long release cycles, we also likely don’t want to target people who crave frequent updates. Doing so would likely frustrate them as their expectations and how Elm releases actually happen will never align.
Relative to language like Haskell and PureScript, Elm has limitations around types. People who consider those type systems to be superior are also likely a poor fit for trying to attract to Elm.
This definitely isn’t an anwser to how to attract people, nor whom to attract, but I think it’s a better starting point than the above comments have put us in. It also gives those who feel that more people should be writing Elm a slightly better way of discussing the topic.
If the goal is to attract more people
In it’s current state I would not recommend Elm to most teams, so I don’t necessarily agree with this starting point.
I use Elm myself because I have invested the time to wade through all the edge cases and devex cruft, but things would have to be different for me to recommend that path to a new developer.
To answer your question however, there are many disgruntled frontend devs at the moment, maybe more than ever, and that is who I would want to attract.