I am looking to understand better and discuss the governance of
elm-packages. The discussion can probably be extended to the docs and other tools. Disclaimer: I’m rather new to using Elm, so the answers here might be obvious to more involved users and contributors. I must say though that I have read/listened to several articles and talks about Elm and it’s governance, so I have a rough idea of the philosophy behind it.
I understand that the governance of the language (and of some of the critical tooling like
elm-test) is a very sensitive thing, and I fully appreciate the advantage of having Evan validate and think through every language change. I feel that it’s a good system and that it benefits the language’s design in the long run. The primary benefit that I can perceive is to avoid adding features that people start depending on, and that get removed later on, or solving the wrong problems, or solving the right problems in the wrong way.
But I do not feel that this requirement should apply to every repository/project of the elm “official” sphere.
elm-packages today, I saw a few PRs that solve basic problems that I (as weel as others, judging by the feedback in the PRs and the issues) have encountered while learning the very basics of elm. Those two are prime examples:
- Display the compatible elm version(s) of the current package https://github.com/elm/package.elm-lang.org/pull/285
- Display the installation command for the current package https://github.com/elm/package.elm-lang.org/pull/295
Those have been sitting here for months, and reading the PRs and the linked issues, there seems to be both :
- an agreement that the features are useful
- no response from anyone as to whether or not this will ever be addressed/merged.
Looking at those PRs accumulating and missing very basic opportunities to provide a better experience for newcomers (to the point some folks have had to create a browser extension to add some of those features: https://github.com/elm/package.elm-lang.org/issues/27#issuecomment-516638844), I’m left wondering: are tools like
elm-packages under the same governance as the language itself? If so, has the relevance of using such governance for such tools been discussed?
The docs, package manager (as far as presenting information goes) are different to the language in substantial ways: their features can be switched on and off, and decisions can be undone easily, without much trouble.
For instance, say we decide to display the install code on the package’s page. Later on, new information shows it was the wrong decision, and we find a better way to solve the install problem. Well, we’ll just remove it! Those kinds of features have very little dependencies, but can still significantly improve the user experience (I personally have had a few highly frustrating hours at the start trying to install a package with a command from an (old) example on a
0.19 project, or trying to find out why this nice package wasn’t available - it turned out to only be available for
0.18. Both of those problems wouldn’t have existed if those PRs had been merged).
So my point here is that such small decisions shouldn’t have to be validated and accumulate on the top contributor’s todo-list, but rather that guidelines could made for each tool category, giving other people the ability to merge such small improvements.
Or perhaps I’m uninformed (and stand ready to be corrected), and there actually already exists a way to do so, but having PRs like those sit for more than a year without feedback seems to demonstrate that it doesn’t quite work right.