What Has Worked
I’ve observed some commonalities among community contributions that have made it into Elm’s core platform—WebGL, Random, Array, and so on. The commonalities include:
- Trust
- Patience
- Research
- Design iteration
- Code
I ordered these from most important to least important to success here. Trust is more important than patience, which is more important than research, which is more important than design iteration, which is more important than code. All seem to be required though. The success stories I’ve seen have involved folks building trust, being patient, doing a lot of research, iterating on their designs a bunch, and of course coding an implementation.
I’ve seen some calls recently for there to be an official process for making foundational contributions to Elm. Here’s the thing:
This is the process.
Elm is built on relationships, not bureaucracy. There aren’t forms to fill out, there’s trust to build!
People have a lot on their plates, and many demands on their time; they need good reasons to believe the time they invest in working with someone will lead to a great outcome. They need to believe that person is committed, that working with them will be a positive experience, that they’ll be willing to put in the hours, to do the research, to iterate on the design, etc.
There is no playbook for how to build that trust, no recipe like “take this action, then this action, then this action, and then you have Built Trust and can check that off the list.” Code is the easy part; relationship building is about people, and people are complicated!
That said, I think it might help to walk through a success story and note a few things.
Example
In early 2016, Evan wrote up some problems with the core Array module. Four months later, @robin.heggelund posted about a library he wrote which addressed some of these problems.
The key here is not the code he wrote, but rather the prose he wrote. Look at that README! He talks about his goals - the problems he is setting out to solve - along with what has and hasn’t been done so far, known issues with the approach he’s chosen for this first pass, ideas for potential improvements, and challenges he ran into along the way.
He’s not making demands of others’ time, or pressuring anyone to prioritize his thing over the other things on their plate. He’s saying “hey, there’s this well-known problem, I’ve done some exploration into it, and here are the results so far.” That is an outstanding place to start!
One result of his post—and subsequent discussions and iteration—was that the next release of the compiler included some optimizations his approach could use for speed improvements. After many more rounds of iteration and discussion (patience was key), ultimately his Array implementation was merged into core.
There was nothing formal about any of this. Robin patiently built trust, did lots of research and design iteration, wrote code, and now his work is a part of Elm. I’m grateful for all the amazing time and effort he put into that project (as well as to his ongoing work on improved Dict designs, among other things), and it’s important to me that I hold myself to the same standard!
Advice
If you think Elm should introduce support for _____ and you want to be a part of making that happen, that’s awesome! Start by building trust. Plan to be patient. Expect to do a lot of research, expect to iterate many times on a design, and expect code to be the easiest part.
If you’re looking for a concrete first step to take, I’d always begin with trying to understand the whole problem. Not just part of it! Maybe you have one use case, but what are other Elm community members’ use cases? What are the relevant use cases people have in other communities outside Elm, which we ought to be aware of? Research these problems and use cases, and post your findings. Talk with people. Ask questions. Be patient!
That’s where I’d begin.
Seeking Specific Feedback
Like I said at the outset, these are observations about what has worked! I know people have many opinions on this subject, but I’m not looking for feedback on whether folks agree with this approach of doing things, or for that matter alternative ideas for how things could be done. The feedback I’m looking for is around communication - specifically:
- Which parts of the observations or advice stood out as unclear?
- What’s a good place to communicate this, such that it can be discovered by folks who want to to build something that requires this sort of collaboration? (If elm-lang.org or package.elm-lang.org seems best to you, where on those sites would you put it such that beginners don’t get sidetracked on it?)