How can the Elm community improve?

Show and Tell
1

A few days ago the article “Elm and why it’s not quite ready yet” was shared on reddit and got a lot of comments. As I was reading through all of them, I felt a lot of problems that were pointed out were already solved. People just don’t know about them.

This got me thinking: How can WE (not Evan, but we) improve Elm? What are the problems in the community?

So I collected all the pain points that I felt we can fix together with existing solution in to an Article.

If you don’t want to read the article, here is the conclusion:

Yes, Elm is not perfect. But this is not all Evans fault and its also not his responsibility to fix everything that is wrong. We can help.

  • We can bring the different platforms closer together. If we have just posted something on one platform, we should tell the other communities as well.
  • We can share the podcasts as well as the newsletter more often. Let newcomers know of all these awesome things that we made.
  • We can continue to share talks. Actually I feel like this is already happening a lot and its one of the greatest things about Elm.
  • We can improve awesome-elm more. This is the first introduction to the community for a lot of people, so let’s make the first contact count.
  • We can improve the docs and write guides. If Evan has problems keeping his guide up to date, maybe we should help out: Write our own open source book. It does not need to be perfect but at least it should improve the parts that Evan guide lacks.

I have also created a reddit thread about the same topic. It would be great if the discussion could go cross platforms.

I would love to hear your opinion on how we can improve our community.

12 Likes
2

To reply mostly to the We can improve docs and write guides part:

I think for that to be feasible a cultural shift needs to happen. Keeping it short, when coming to Elm one does not have the feeling that small contributions, like doc-changes, are wanted, welcome or assisted.

My Experience:

Before diving deeper into Elm, I learned Rust. The experience there is so very different. When complaining about documentation, Steve Klabnik will show up and tell you to fix it yourself (kindly). And it works.. Not only is the responsibility shifted to the person complaining, they are also feeling more as part of the project than a consumer.

In conclusion: Community contribution is not a one way road.
To quote Linus:

So please don’t stop. Yes, those trivial patches are a bother. Damn,
they are horrible. But at the same time, the devil is in the detail, and
they are needed in the long run. Both the patches themselves, and the
people that grew up on them.

18 Likes
3

Elm’s approach and target is just different from Rust. Rust aims to be a good language that the community loves, while Elm’s priority is not to please the community, but the consistency of the language and enterprise adoption afaik.

Evan specifically wanted a different kind of open-source community for Elm: The Hard Parts of Open Source and the path is more relationship and trust based unlike other open source communities that encourages a flat structure: What is “constructive” input?, where he emphasizes “All of us make choices like this because we have a personal relationship to the work and each other that makes it worthwhile.”

Guides and docs are crucial for early adopter’s experience and hence any change I think requires Evan or any of the core member’s trust, instead of long blog posts/comments/pull requests with reasoning that would waste their time.

For the improvement of Elm Evan has a list of encouraged tasks to contribute that fit into his mental plan of Elm: Elm Projects.

Other than that, according to Evan’s recent tweet, you can make something in Elm, especially big projects, and write a report on why Elm is good choice for this. https://twitter.com/czaplic/status/1097966421009752070

I tried to use Elm for prototyping small web projects and found a lot of obstacles in the learning process due to the uniqueness of the Elm community. But compared to other competetors (ReasonML/Purescript) the Elm community is much better. Rust is a good choice but it is not there yet for front end.

2 Likes
4

That’s actually the point I was trying to make :slight_smile:

@Lucas_Payr argues, that the community should support with documentation and guides.
You and I argue, that that does not seem to be something the Elm core team wants and supports.
I have to admit of course, that my reply is somewhat emotional and biased and that I would like it to be different.

1 Like
5

I maintain a few elm libraries, and for what it’s worth, I’ll share a little perspective on that experience. I put a lot of thought and effort into guiding these libraries in a good direction, and keeping them well-maintained. And I think there are many people who will say it was a great experience when they requested a feature, asked for help on Slack, or contributed to one of my libraries. However, I’m sure there are others who feel frustrated that I didn’t get to their issue quickly enough. And of course there will always be some people who disagree with the direction of a library, so they’re unhappy with some decision.

Even though I’ve put a tremendous amount of effort into being responsive, I often fall short. I have several open issues where I haven’t responded at all, or for too long. Despite all the effort I put into staying on top of things, it’s extremely difficult to keep up, and to triage effectively.

I know that Matt is the same way with Elm UI. If you look at his recent OSS contributions, he’s doing a ton of work, and he’s constantly taking time to answer questions in the Elm slack, working on ways to make the documentation great, and making his libraries easier to use. He also has a lot of detailed discussions on issues.

I’m not excusing having open issues that don’t get responses, I’m just saying that I completely understand it, and it’s a difficult problem. I wonder if some sort of community contribution could help with this kind of thing? Maybe people could volunteer to help triage simpler issues?

All of that said, here are a few things that have worked really well for me.

What’s worked well for me

Find ways to allow people to do their part (easily)

I’ve really enjoyed the approach of trying to involve the community when someone says they have an issue (similar to the Rust approach). I recently had a bug filed that was a little subtle. So I asked the reporter to create a minimal reproduction. This required trimming down a GraphQL Schema and re-running the code generation CLI repeatedly, which is tricky if you don’t have some tooling set up to help you with that. So I invested some time in writing some docs on how to reproduce an issue (and why I ask people to do so). And I built a small script to help with the process. The script and docs live here: https://github.com/dillonkearns/elm-graphql/tree/master/reproducing-issues.

This was a big win! Fortunately, the reporter of the issue was really appreciative and willing to help, so it was a delightful interaction (on both sides, I think!). The reporter was even kind enough to give me a failing unit test case that I could use to quickly make a patch.

Interactions and attitude

The reporter’s attitude and tone can make a big difference for maintainers. In this case, the reporter was really grateful and willing to pitch in. For me, I find it really emotionally taxing when my interaction feels like it’s coming from a place of expectation, or wanting to get a feature a very specific way rather than recognizing that it’s part of a bigger vision that needs to be discussed and examined.

I’ve considered adding something to this effect in a code of conduct, but I hesitate because I want to make those things emerge through the interaction rather than needing to “police” behavior. But maybe that’s just me. The things that I’ve found really help contribute to a better atmosphere (and that I can do as a maintainer):

  • Have humility - Even if I “know” I’m right, I try to come from a place of curiosity. Very often, when I thought I was “right”, the humility pays off because I end up learning something that I wasn’t considering. At the very least, the interaction is a lot more pleasant that way on both sides!
  • State explicit core values/philosophy in README - This let’s you collaborate to find a solution that honors those principles, rather than arguing about different approaches. Instead of “X is the best solution to Y,” I try to say “Can you think of any ways to solve Y that are in line with <core philosophy point 1>?”
  • Ask questions to dig down to the problem - it’s very common to have XY problems in feature or bug requests. No need to “correct” anyone, though, just ask a few questions, and the conversation tends to turn towards the bigger picture.

Document knowledge when it keeps coming up

A lot of the community interactions take place on Slack. This is great in a lot of ways, but it does indeed end up with questions coming up repeatedly because it can be hard to find answers. When I find myself answering the same question more than once, I write the answer in this FAQ doc (in the case of elm-graphql), and then send a link over. This also allows me to invite people to make a PR if something was missing, or not clear enough.

Strengthening the elm community

@Lucas_Payr, I love your thoughts on how we can focus on what we have the power to do right now. I totally agree! Perhaps that FAQ technique I’ve been using for elm-graphql (documenting things when they keep coming up) could be something that we as a community could start doing? There’s a lot more to explore here, but I’ll leave it at that for now :smile:

18 Likes
6

Hello!

Just a brief note for the feature/PR you submitted to elm-ui for being able to batch attributes.

I’ve discussed that feature extensively on the slack and am aware people want something like that. It’s a weird one because it’s simultaneously a small change, but one that would likely have a large effect on how people organize their code.

It’s a large design decision and I’m hesitant to make that decision lightly or without exploring other options.

I likely should have noted that on your PR or somewhere less ephemeral than slack, and I’m sorry you didn’t get a response. :confused:

Relatedly, it’s been on my mind for a while to put out some docs on what my process is and what types of contributions are the most helpful to the project. I’m pretty maxed out as far as my capacity, so I’m looking for solutions that aren’t just “Matt does more”. I’ve even toyed with the idea of hiring a virtual assistant to help manage/communicate with the community on the repo. Maybe I’ll look into that further.

8 Likes
7

1.) Stop banning people who share their opinion, simply because you dislike it.
2.) Stop advertising Elm as production ready and “we have thousands of lines in production” so long as the language is a moving target and changing essential features from release to release. So many people are angry about this and moving away.
3.) Succeed with all the awesome stuff you already do.

You = The Community.

2 Likes
8

Intentional Communication

2 Likes
9

Thank you for your answer! I’ll quote some of it in the PR so other people know as well.

3 Likes
10

Some other things, which are mostly project based, that I keep coming back to:

  • I think the package website could be better. It feels like evan is struggling with time, which is understandable. So I either hope that he finds someone he trusts and maybe let that person work on that page under his vision. Another way forward would be to fork the frontend part of the project and improve that in a different repo. Then host that somewhere, while it still speaks to the regular backend.

  • I’m really looking forward to a possible new debugger with https://github.com/opvasger/elm-devtools not sure if he needs feedback or help at the moment.

  • The other problem to me was tooling, which I’m working on with some other people.

11

I’m happy everybody haven’t forgotten :smile: I’ve had less and less time to work on it since the preview. But I’ll get there eventually.

8 Likes
12

The lack of diversity of the community is my biggest concern by far. The Elm community here and on Slack seems to be super overwhelmingly white guys. There may be any number of reasons for that, and I super appreciate that conferences in particular seem to be trying to improve it. But it’s still significant.

I would love to see more events like ElmBridge in more places. I may be wrong, but it seems like the only people I’ve seen organizing ElmBridge events so far have been women. You don’t have to be from an underrepresented group to organize events like this. I’d also like to see more reaching out to other communities specific to women, people of color, queer people, etc, when we advertise events, when we look for conference speakers, etc.

Community diversity problems are like technical debt — they only get more entrenched and harder to solve if you wait to fix them. I hope to see us focus a lot more strongly on this in the future.

5 Likes
13

This is most likely a base rate problem. My impression is that Elm Community tries to do its best in this regard but some issues are just very hard to address.

14

I wish we had a woman organizer, but currently ElmBridge Berlin is organized by white men.

1 Like
15

I wanted to take the opportunity to talk about Chris’s post and Lucas’ followup on the show this week. There’s no magic answer here, just trying to work through my own feelings about the articles and find out why both posts resonated with me. My hope is that it helps continue what I feel is a healthy discussion and am excited to see what comes out of it.

JavaScript To Elm Episode 83 “Elm Community”

2 Likes
16

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.