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.
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:
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.
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.
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.”
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.
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.
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.
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:
A number of people have been burnt badly trying to contribute. Like Luke and Dan, but other stories come to mind.
People are recommending Luke’s blog post as introductory reading about Elm.
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.
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?
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.
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.
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.
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.
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…