Communicating about Elm Contributions

This is the Nth time this issue has been discussed - and doing so has changed nothing.

I agree there may be a better process. I think the only way you are going to get one, is to fork.

It has been specifically told in context of Elm that PR:s should not be created, everything should be reported as an issue, even if the fix is trivial.

Also I’m certain that that isn’t the only serious bug in String, given how idiotic String evan has designed. I would be willing to debug it and find more bugs/fixes if there were even a slight chance of those getting fixed. But it’s clear that Evan just doesn’t want to fix certain bugs, no matter how serious they are.

Which is why I’ll settle for documentation of the process we already have :stuck_out_tongue:

1 Like

I’d fork Elm if compiler were written in Rust, but I have no interest learning Haskell.
Anybody interested in re-writing Elm compiler in Rust?

This seems to sum up the current process in its entirety:

  1. There is a core group of people who make actual choices and sacrifices to try to make a nice thing here. Part of that core group is that we actually like and respect each other.

Don’t forget point 2:

  1. Infinite unsolicited advice from strangers is the part of this job that makes us want to quit.

So that awesome hard-working core group doesn’t want any advice from outsiders. THEY are the ones who find bugs, fix bugs, etc., outsiders are NOT allowed to help at all.

Yes, this does sum up the current process in its entirety.


That description really doesn’t answer any of my questions, much less make it easy to compile and direct people towards the relevant information. So we’re back to first post of this thread.

Anyway, I get that everyone involved are doing this for pleasure, and are making sacrifices to do so. It’s also no surprise that there’s demand for a “better” process (whatever “better” means to each of us). But I think this thread is about as strong a motivator as we can get, that the current process at least causes notable harm.

Whether this is something the people in power want to change is for them to decide. And maybe some change has already occurred in the last months! I have no idea at least, because there’s poor transparency.


At least, what we can actually do, is give insights, exposure and overlook to the development of packages outside of elm core.

Elm core is a black box, and I guess that is mainly because of protection of energy, resources and motivation. I guess we have to deal with that now, and for example propose “official” constructive feedback outside these forums for archive. Create articles that are complementig and showing a ‘how elm and the packages work behind the scenes’. This is work.

There are so many compentent people here, which could actually do a lot for the community side things in terms of communication.

Let’s do not fall into bikeshedding. It is clear now, that there are problems for a lot of people… lets fix that with the tools we have

Edit: One article to sum it all up (honest) would be enough, so that we won’t create fragmentation again…

You would not necessarily have to do much with the compiler - unless of course you are interested in fixing compiler bugs. Mostly, you would need a hacked version that is not restricted to elm/* and elm-explorations/*, but is capable of substituting some other GitHub org or completely alternate git source for them. Then you could apply bug fixes to the core packages, which is presumably the Elm and JS code that is most of interest to you.

I think a third-party package management tool for Elm could go along way toward opening it up, as well as also solving the issue around not being able to publish/consume private packages. It may not even be necessary to hack the compiler, if the package management tool downloads substitute core packages into the ~/.elm folder.

Its sort of been on my mind to write a spec for this tool to get some feedback on the idea.

(Just started a new job though, and in the midst of open surgery on my pickup truck, not mention home schooling the kids in Covid lockdown, and trying to finish my text editor in Elm that I started…!)


I think a third-party package management tool for Elm could go along way toward opening it up, as well as also solving the issue around not being able to publish/consume private packages.

Might want to take a look at Grove, which I believe is an existing project for roughly what you are describing, while it appears to have been abandoned, it might be worth looking at if you wanted to try something like that.

Thinking this a bit more, this actually sums up clearly the difference between Elm and other open source projects:

Other open source projects:

When issue is reported, main question is whether reported issue has merit. If it has, it will be acted upon, regardless of whether the person reporting the issue is known to the project or not.


When issue is reported, main question is whether Evan has asked the person reporting the issue to contribute to Elm or not. If Evan has done so, issue will be acted upon. If Evan has not done so, issue will be considered unsolicited advice and will not be acted upon, regardless of whether the issue itself has merit or not.


If you want to contribute to Elm, wait until Evan asks you to do so. Do not contribute before Evan asks you to do so as any contribution you do would be considered unsolicited advice.

1 Like

To get back on topic, I think this discussion itself proves the point @KasMA1990 is trying to make.

We really need more clarity and transparency regarding contributions.
This would avoid frustration and wasted time. Time is valuable, not only for the core team.

I have one suggestion, that I am willing to contribute to:

  • Write a detailed ‘Contribute to Elm’ page, separate from the elm-lang site.

This can be created by the community, and the core team could review it. If the core team decides to integrate it in the elm-lang site later on, so much the better.


Has some similarity to my idea. My main motivations are private packages, and decentralization of the repository for robustness - when the package site is down. The ability to override core packages is a feature to consider, and not without its controversies. So I will probably not even include that in the first pass.

So I am thinking such a tool would come in 2 parts:

The first would be a command line tool:

  • Install packages into elm-stuff.
  • Add the ability to source packages from somewhere other than the main package repo.
  • Would NOT allow you to publish to the main elm repo, you still have to use elm publish for that.

The second part would be a server process than manages a repo. This would be set up to

  • Mirror the main repo. You can still work if the package site goes down. You can cache packages on your local network for faster clean builds.
  • Download and checksum release .zip files in such a way that the checksum reflects only the contents of the release - not its github coordinates. There have been issues in the past with checksums being wrong due to name changes on github not working through redirects.
  • Allow you to publish to your private server.
  • Allow you to publish alpha versions below 1.0.0 to your private server. I guess the compiler might not like this? So perhaps that can’t be done without compiler changes.

The set up would be analogous to how Maven (command line tool) and Nexus (repo manager) work in the Java world - just without being quite so… ugly.

That is pretty much it, might as well write this spec up a bit better now that I have started.


Phew, this thread is revealing lots of frustration but I wanna answer to @KasMA1990 again to his original.

I agree those would be good measures to make the procedures of Elm more obvious up front without people having to scan through threads like this.

  1. the Governance seciton on the website would be helpful. But since it is doubtful that Evan would accept a PR for this, it is something Evan would have to do. So to get that done you would have to convince him it’s good idea, which kinda takes you back to step one.
  2. Adding a to repos would also help to make current practices more clear. I believe the content would need to be something like Contributions are not takes into account unless initiated by the Core team. if filled out honestly.
  3. I agree.

If none of that is doable for lack of consideration, then I guess your only route is to make a community website that explains those topics. The hard part will be to make it visible enough and getting credibility since the content wouldn’t be coming from an official source.

  • Write a detailed ‘Contribute to Elm’ page, separate from the elm-lang site.

This can be created by the community, and the core team could review it. If the core team decides to integrate it in the elm-lang site later on, so much the better.

Yes, please. Where to start ? We need to aggregate information.


We could set up a repository (maybe over at elm-community?).

That repos could also serve as archive for interesting discourse posts. Currently, I feel like everyone has their own little collection of bookmarked discussions. This way we can ensure that good discussions don’t get lost.

In case we don’t get a repos at elm-community, I offer to start my own repos. Any Ideas how the repos could be called?

1 Like

We could name that repo “elm-communication-workgroup” - I’d go for it, if we create that repo in elm-community that’d be great. Otherwise we could create an organization called like this and create a repo there … I would be in participating !


I think it could be really nice to have an “official” community site hosted via github pages. I’d suggest naming the repo something simpler like “community” so the site would live at

I believe IS the “official” community website.

From what I understand, repositories in elm-community are mostly forks of other repositories. The official way to get a repository added is to create a PR over at elm-community/Manifesto. This would mean that we would probably have to start the repos somewhere else. Personally I don’t see the need to create an organization just for this one repos.

Regarding the name, I would lean towards something like “elm-archives” or “elm-discussions”.