Communicating about Elm Contributions

Learn
1

I’ve begun to think more about how the restrictions of contributing to Elm are communicated lately. The reason is that I’ve now seen two posts on reddit (on different sub-reddits, here and here), which cautioned newcomers about those restrictions, and recommended they read about them by reading the all time top posts on the Elm sub-reddit.

The actual top post is Luke’s blog post on leaving Elm (discussed on Discourse as well), which is not a great way to start someone off with Elm. Both the aforementioned reddit posts are, as far as I can tell, trying to set expectations for the newcomer. Elm doesn’t operate as many other open source projects do, and many people seem to care about this aspect.

So I tried to figure out, how are the restrictions that are in place actually communicated? Is there a document we can point people to instead of Luke’s blog? And the answer is: not really.

There’s a number of tidbits here and there, like this quote from the elm-lang community page:

So given our goals and resources, we have found that having good working relationships is crucial for collaboration on core code.

The same page also points to several YouTube videos, like Code is the Easy Part. That’s all on that page though.

Then there’s also a GitHub repository called expectations, which is a collection of best practices for how to successfully contribute to Elm core code. I haven’t seen any links to this repository though. There’s also the projects repository, with ideas for projects to collaborate on. This page also links to Code is the Easy Part on YouTube, as the introduction for how to contribute to Elm. It also points to the roadmap, that was published while 0.18 was the newest Elm release.

In my opinion, this means there’s really no single summary of how you can contribute to Elm. You have to piece together much of the information from disparate sources, and just looking at the above links, there’s still some gaping holes to be surprised by, like:

  • You can’t compile core Elm code without being a member of the right GitHub organization
  • How do you become a member of said organizations?
  • Does it require the aforementioned “good working relationships” first, and how might you build that?
  • It’s common knowledge that Evan is a busy man, so should you try and get a good relationship with him, or is it better to talk to someone else?
  • What’s the difference between core and elm-explorations?

I’ve been frequenting this community for a few years now, and I can’t answer any of those questions, so I doubt newcomers stand a chance. In fact, my impression from spending time here on Discourse, is that trying to contribute as much as a spelling correction requires years of patience, and may never be met with more than silence. This impression is based on posts like this and this. But this impression also seems to be counter to the praise that Evan gave Bekk and Robin in this blog post for their contributions to Elm.

I have three concrete suggestions:

  1. Have something like a “Governance” page on the main elm-lang site, which explains the restrictions around working with libraries containing kernel code, the purpose of elm-explorations, and so on. It should also link to the expectations repository. Describe what it actually takes to contribute code, so people can better judge if it’s worth trying. How do I start building a good working relationship without opening pull requests?

  2. Add CONTRIBUTING.md files to every repository in the elm and elm-explorations repositories. The only ones with such a file, at the time of writing, are webgl and linear-algebra. I imagine many people will try and look for these descriptions, and they can link back to the governance page, and add instructions that are specific to the repository.

  3. Don’t refer to YouTube videos for important information. It’s fine to have those videos, but if there’s something important in there, it should be available in writing as well. Videos are very poor for searching and skimming of information.

In short, being more transparent about all this would be good. Feel free to critique my findings and ideas, and add your own as well :slightly_smiling_face:

26 Likes
2

Hi @KasMA1990 ,

you’re observations are shared with many in the community. While the topic is a large one, being a frequent Elm community member since 2017 I can share some of my experience.

I agree. I’ve seen those kind of posts several times throughout the past years and they are terrible if you’re trying to convince someone to try Elm and that’s what they find. The frustration that led to these posts is in my opinion partly due to restrictions and lack of opportunity to contribute.

That’s the core of the issue in my opinion. I haven’t seen lots of community members be able to contribute in a way that actually leads to progress. From what you can read online Evan often wants people to do lots of research before they can contribute, which means the bar for contribution is high, which I consider a good thing. On the other hand, some people actually seem to do the work (example here and here ) and still nothing happens, which is super frustrating to do a bunch of work only to get nowhere.

I am not sure that his busyness is the problem here. Apparently Evan is paid to work on Elm full-time so and can choose freely what he is working on. I think Elm is brilliant and the way that it does things differently is courageous. BUT to me there has got to be some middle ground between asking for everyone’s approval in the community and basically refusing to interact with the community on a frequent basis. Coordinating many helping hands requires time and of course Evan’s time is valuable, but to me that doesn’t mean that it shouldn’t be done at all. I think Elm could grow pretty well and stay true to its ideals with a little more opportunity for contribution. Even if community won’t be involved in design decisions it would be great if they at least got a chance to fix some of the long outstanding bugs and issues (like this one or this one) especially if some of them are one-line fixes.

I believe there was a bunch of angry discussions between Evan and the community memebers before 0.18 (before I joined the community) that lead to the situation being the way it is now.

I still very much enjoy using Elm and being a part of the community and I hope that the path for productive community engagement will open again someday. But that depends in large part whether Evan thinks this is good use of his time which probably isn’t the case right now. Anyway good to bring this topic up every now and then.

1 Like
3

And ‘hi’ back at you :wave:

We agree that there are more fundamental issues at play here, and I have my share of ideas on how to solve them too. I would prefer to keep those issues and ideas out of this thread though, and focus on how to gain more transparency into a process that feels like a very black box.

This is my feeling too, and I share some of those frustrations. Trying to contribute to Elm feels like starting down a dark and twisted road, which for me means not even bothering to try. But maybe we can shed some light on it, and the road might just turn out to be actually manageable without having to change it.

2 Likes
4

I totally agree with you, both. I am also in since 2017, and for me it feels the elm community is not really evolving, kind of stuck. The are no roles created to manage the community, actual development<->community communication is basically non existent. Any Documentation beyond elm technicals is literally a puzzle every newcomer has to solve on his own, and then some people might get baffled about what happens when they want to contribute anything. I think it is extremely important to clearly and directly communicate what to expect when people come to the project (videos and fragmented github links do not do this). Also, what is evenly critical is a clear and open communication on how to include (new) people in the community and to see and be open for new roles. An Agenda on how to evolve Elm beyond technicals might be a good first step. The current state could feel for a lot of people (which are used to ‘common’ open source) that Elm is kind of an academic elite community …

Wanting to design a perfect language for a use case is fine… But “gatekeeping” Elm might lead people to see the big picture that Elm is actually not this user friendly as it promotes …

Creating a bigger picture on how to deal with the future and on how to grow the community healthier, instead of working in these ‘absolutes’ might be a big win for us.

3 Likes
5

The technical quality of Elm should also be applied communication and documentation wise. There is no way a few people can handle this. Also: Have a look at the Python project and community as inspiration :slight_smile:

1 Like
6

For a very recent example of how new changes can get proposed and semi-implemented, check out https://discourse.elm-lang.org/t/a-faster-list-map-for-elm/. This thread is a great example, IMO, of how various memebers of the community have come together to suggest an improvement for Elm, have a plan for testing it, and Evan even responded to it. This is also a very “minor” change compared so one can see that there’s still a lot of process involved.

Alternatively, I wrote on /r/elm a few days ago about placing more focus on the Elm ecosystem and not just the compiler/core language. There’s a ton of active and frequently discussed work going on around tooling that is both highly important to any language ecosystem and is often ignored. You can check out GitHub - jfmengels/awesome-elm-sponsorship: Elm profiles to sponsor for a lost of people who are putting a lot of work into tooling and could probably use a lot more help than Evan. I don’t know this for certain as I’m not a contributor to these or to the core team. Just the sense I get from listening.

8 Likes
7

I see, interesting… However, the problem which I see here is, that the way of collaboration is kind of hidden and heavily under exposed. I often wonder ‘why are people toying with these proposals only to get them buried after 10 days of no response?’ - isn’t this a clear mistake of communication ‘by design’ ? People did propose a lot the last year, but I always had the feeling ‘for what’ - there is no real platform for this… these things often get buried in this forum. Why is there no official page for proposals ? Well documented and trimmed to the core ideas and pros and cons ? With threads separated from the forums for serious efforts ? Where do these ideas, efforts and energies go to ? For me that is not really a grown up way to seriously go for the future and do something about how a project faces the outside world also. Elm could do hugely better on top what already exists.

1 Like
8

Summary: You can’t.

True. doc error: JavaScript safe range starts from -(2^53 - 1) not from -2^53 · Issue #1081 · elm/core · GitHub (ok, this is only 9 months old, not years yet)

1 Like
9

I think a development page like Elixir has, would also fit for Elm very well. It is communicating very well and brings diversity and fairness into mind and also settles a healthy approach to the given expectations. I think this energy should also be invested in Elm ! That is the important factor: How to manage energy and expectations, so that everybody understands it properly. Being honest about anything involved (downsides…) is key here.

1 Like
10

The current state of communication for contribution is this: https://elm-lang.org/community#participate

We have primarily volunteer labor. One full-time dev, but outside of that, it is people working on nights and weekends because it is fun. This makes it hard to get to issues and pull requests as quickly as projects with paid “developer relations” staff to focus specifically on online interactions. So given our goals and resources, we have found that having good working relationships is crucial for collaboration on core code.

If you are a company evaluating Elm, I encourage you to DM if you are worried about something, and it is totally reasonable to circle back to Elm later!

I think this leaves room for a lot of confusion and frustration and needs reworking and way more transparency and honesty. Also, as an Individual I get the feeling, that only companies are treated as relevant when they are worried about something in Elm…

So given our goals and resources, we have found that having good working relationships is crucial for collaboration on core code.

Which goals ? Hmm …

This needs some extra love !

11

While those are good links, I’m unsure what you are trying to add to the discussion with them. Adding transparency on the current process and inner workings of the core and elm-explorations organizations would address a few needs:

  1. Reduce fragmentation of information - Right now you have to pick up a lot of information by being in the right place at the right time on Slack, searching the forums or GitHub, picking stuff up from long videos, etc.
  2. Reduce confusion on how the Elm community works - There are plenty of stories about PRs that never get responses, but also stories with successful contributions. What makes one different than the other? It’s actually hard to tell the difference for many of us.
  3. Have a good document to link to - Let’s not recommend people learn about Elm by reading controversial posts from people who got burned from trying to contribute.

The main point I want to address is not necessarily to get more people actually contributing to core and elm-explorations projects. It’s mainly about getting some certainty about how things work. Maybe once we have more transparency, people will be better able to judge where their effort should go. For example, a Governance page could also point to that list of tools that need help, as places that are easier to get started in. But having it be very visible in the GitHub repositories is important, since I think many people start there when they consider contributing (which is where the CONTRIBUTING.md files come in). Then people can see “Okay, there’s a very high bar for making contributions here, but I can start over here instead.”

5 Likes
12

I agree deeply with all what you propose… The problem is, that this just has no priority at all (or has it?) … hopefully someone can correct me on that. I am afraid, unless there is real holistic communication (and someone who is actually able to change something) this will be buried too.

13

We may never know what priority this has. I’ve tried to keep the scope of my suggestions small, so they may hopefully be manageable enough for someone to just go ahead and implement. My hope is that someone with the knowledge and the access will be inspired to do something about it, even if “hope” doesn’t make for a great development process.

1 Like
14

I rarely bother with “Proposal: New idea for Elm …” posts. I don’t think there has ever been one that has changed even one thing. They can occasionally be fun or interesting, but that is the limit of their value.

I notice that sometimes there is a post where someone says - I did some work and got this interesting result. Those seem far more likely to engage with our BDFL.

So I deduce that Evan does not take interest in people proposing things that give him work. He may take an interest when someone has done some work, but it is no guarantee that it will go anywhere.

elm/* is very stable and slow changing. If you want to contribute, you are better off focussing on the package ecosystem, or third party tooling, which are completely open to contribution. That is where the action is.

To my mind this mostly makes sense. Its good software engineering - the stable parts have been modularized and evolve slowly. Its hard for people coming from other frameworks which change faster, but the truth is that elm/* does not need fast churn because it is better engineered from a software/systems/social perspective. I say ‘social perspective’ because our BDFL clearly needs to give himself freedom and space to work in his own way and at his own pace. Its obvious that he cares about this project a great deal, so I conclude that his working style is just going about things in a way that lets him maximize his effort-to-reward ratio as a contributor.

My one complaint would be the little bug fixes that never get merged in. Strikes me that there can be a good effort-to-reward ratio here, if some time were spent reveiwing and merging in little fixes - the “gold dust” of open source.

8 Likes
15

I have no interest in changing what Evan wants to do or how to best add something to any part of the Elm ecosystem. The core issue I want to get at is exactly this:

All the guess work the rest of us have to do. You’re a stalwart in the community, and you’re still guessing. What I’m getting from your post though, is that you don’t believe there is any need to guess. We can just accept that things are as they are, because everything is actually okay.

I don’t believe this is true. There are surely a number of ways the process around Elm development could be enhanced (depending on what you want to achieve), but I think it’s worth assessing some things that are currently wrong:

  1. A number of people have been burnt badly trying to contribute. Like Luke and Dan, but other stories come to mind.
  2. People are recommending Luke’s blog post as introductory reading about Elm.
  3. We don’t have an answer to either problem. If you’ve been burnt using Elm, no matter how badly, there’s no empathy. Have you considered using a different language?

(This list is not exhaustive, but those are at least some points that are relevant to the topic)

What if you’re the next one to get burned? You, @rupert, are probably not, because you’ve got enough experience with the community and the philosophy behind Elm. But what about all those who don’t? They’re left to guess, and many of us here have to just guess as best we can.

I have a feeling this significantly limits the community. And the first step, in my mind, is to add more transparency. A hypothetical Governance page could just say:

If you make something cool, you may get it merged. It’s very rare though, so don’t aim for a merge. Preferably you should spend your time and energy on something outside what the core team is involved in.

But I think we can do better, because that’s clearly not the whole answer. Evan has requested more contributions, and there’s still questions like “Okay, if I can’t expect a fix to be pushed to a core package quickly, how can I patch it myself?” (you can’t), or “Why isn’t my simple spelling correction PR getting merged?” (it’s anyone’s guess).

The point here is not to funnel more contributions into Elm, but simply to provide understanding for how things work. For the benefit of everyone hopefully.

4 Likes
16

What are you smoking? elm/* has serious bugs like Infinite loop in String.toList which cause infinite loop e.g. in elm-test and can crash vscode.

17

While I think this could be clearer early on, but if you actually create an issue you will get a handy bot response. Like here: doc error: JavaScript safe range starts from -(2^53 - 1) not from -2^53 · Issue #1081 · elm/core · GitHub pointing to stuff being worked on in batches.

Judging from the last release cycles this is true, most of my PR’s fixing typos were not fixed, as evan cherrypicked (or just copied?) it into his branch. So yeah, that will look bad too.

Another problem which is out of scope for this discussion, in my opinion is, that elm releases break the whole ecosystem, so in my mind, that’s also a reason. Yes, typos could be fixed in master now, but what’s it worth, if there is no new compiler release?

3 Likes
18

As one of your examples, I’ll chip in to say there is definitely a problem here.

Contributing towards Elm feels like throwing effort into a black hole right now. I understand the intent behind the process and approach taken by the project, but the current state feels like it is just leading to people putting in effort, working to match the stated goals and workflow of the project, which is just discarded out of hand.

I went in kinda expecting that, honestly, but I think presenting Elm as a functioning community project when it just isn’t accepting any outside contributions right now is a mistake.

4 Likes
19

I did mention at the end of my post that this is something I feel more attention should be given to. In this case there does not seem to be a PR, but someone has contributed a solution in the Issue report at least. Ideally it should be a PR that can be reviewed and merged in, in say ten minutes. Its a little disheartening to see easy fixes like this sitting around and missing releases - a bunch of them could have made it into 0.19.1 for example.

20

I believed for a long time that everything is okey but then -as it can happen to anyone- I was stuck with a bug and down the rabbit hole I went. Ones you know that major bugs exists you feel like every little problem within the elm/* could destroy your project.

My last issue was elm/svg not having a way to add custom attributes. Looking back, I apparently didn’t even bother to add an issue.

Now with the new project - that needs elm/parser - I noticed that Parser.deadEndsToString has no implementation, and I feel like that happens every time I use elm/parser.

I’ve just realized while writing, that I’m so used to these kinds of small bugs, that I don’t even bother making a fuzz out of it. Although both issues exist even before 0.19.

I’m burned out trying to change anything about it.

6 Likes