EDIT (2021-11-20) to add some summary to this thread (there’s no “Mark as answer” but I’d mark Terezka’s post as one).
The answer to my questions below is that there are no official plans to change the current Elm process of how open-source contributions / package maintenance is dealt with. The situation and concerns are noted; to quote Terezka, "the current strategy is a deliberate choice."
In my mind it has been helpful to think of Elm as Evan’s personal project, research language, source-available, “no promises.” The fact that it’s been very usable and productive choice for companies and developers is a great success, but it’s almost “by accident,” and doesn’t force a responsibility on Evan to change anything about how he approaches the project’s future.
In that sense, the fork option, while more time-consuming, makes a lot of sense in that the community can say “This new language X is based on Elm 0.19, but it’s 1.0 in the semver sense; you can migrate easily and it will not introduce large language changes and deviations from Elm 0.19 but will receive maintenance care and bugfixes and the package API will be able to evolve; and we will handle open-source contributions in a transparent community-led process.”
Essentially, sending a signal to companies: “This is stable and maintained, you can depend on it,” and giving Evan back tthe space to take Elm where his explorations lead him.
The question is, while this is a cleaner solution than eg. patches applied by tooling on Elm libraries, do we have enough resources as a community to make the jump?
End of summary edit
I’d like to start a respectful discussion between @evancz and the community about the possible ways to improve the situation where
elm/* libraries don’t get attention and care fast enough due to the batched maintenance model, and the “time-to-being-dealt-with” is realistically measured in years rather than days/weeks/months.
A few examples:
deadEndsToString or the bug about
int committing to chomp
maybe should be discouraged
• elm/core: performance improvements without API or behavioural changes (also see
I probably don’t need to describe the pain points these create (that horse has already been beaten to death), and I don’t want this thread to become a list of “me too!” reactions.
I’d like to instead ask @evancz what criteria would a solution have to pass before it would be realistically considered, and discuss/draft possible solutions that meet them.
For an example, let me draft a (flawed!) proposal of how we might make the overall maintenance situation better: keeping space for big changes at the beginning / as the muse strikes, but allowing a judicious way to handle fixes / improvements to a library.
elm/*packages start in an HOT mode: Evan’s actively working on them / monitoring their usage, batching issues/PRs and possibly drafting a new API, etc…
after Evan indicates he’s moved on to something else or after some time period (eg. 6 months since last Evan’s version), the package switches to a COLD mode (forgive me the simulated annealing metaphor ) - the maintenance burden is shared by Evan with a set of maintainers picked (trusted) by Evan; the maintainers vote on PRs and make patch/minor semver commits, while major version bumps would need Evan’s approval.
Evan can move a package from COLD mode to HOT mode at will
Evan has a veto power for any PR
I have a feeling something like this might let non-controversial improvements through without Evan needing to spend time maintaining all the libs and react to all the PRs and issues. So, passing the ball to Evan’s side of the court:
Evan, what are you generally thinking about the “small fixes” maintenance need for
elm/core etc. repositories?
Could you please share whether you considered some other-than-batching maintenance model (perhaps in later stages of a project) and what criteria would such a model have to pass? Also, any thoughts on delegation? Generally, how to move this discussion forwards?