[ANNOUNCE] elm-community status changed to "sunset"

rupert · January 13, 2023, 1:41pm

It was decided by approximate concensus that the elm-community GitHub org, should not take on any new packages. Instead, if an important package becomes unmaintained, users should just fork it themselves if they want to continue maintaining it. This could make it harder to find the right package amongst many clones, but has other advantages as a more asynchronous way of working.

It seemed generally accpeted that the various *-extra packages that exist in elm-community, are a good set to keep there, and should continue to be maintained there.

You can find the discussion (temporarily) on the Elm Slack #elm-community channel, if you wish.

The guidelines have been updated to reflect this new status, and Evan provided a short history and summary of the GitHub org.

github.com

elm-community/guidelines/blob/master/history.md

## History

This organization was initially an experiment in code maintainance. Can **decentralized** people maintain packages over many years under a **centralized** GitHub organization? And can they do so without any funding for managerial overhead or for training and supporting new maintainers?

### Lessons

The people who initiated this experiment ran into some rather predictable troubles and were not able to keep up with their initial vision. Over time it became clear that a more traditional approach (which has its own problems) would still work better overall. In the more traditional approach:

1. Packages are created by independent authors under their own name, like `alice/typed-svg` or `bob/easing-functions`. Authors run projects however they want, and the packages succeed or fail based on all the factors that go into that. Code quality, API design, blogs, docs, conference talks, etc.

2. If the needs of certain users do not match `alice/typed-svg` or `bob/easing-functions`, certain users can decide if it is worthwhile to make their own version and take on the full burden of development themselves. If it is not worthwhile to them, they will not do that. If it is worthwhile to them, they will do so under their own name and the package will succeed or fail on its own merits. Not by piggybacking on the reputation or usership of an existing package or organization.

This is a **decentralized** way for **decentralized** people to end up with the code they want. There is no central point to ask permission for anything. And there is no official sounding organization that (with prior versions of this repo) might dissuade potential new package authors from pursuing their vision of a particular package. If your needs do not match what is freely available online, the next steps to solving your own problem are fully in your own hands.


### Current Usage

No new projects are added, and existing projects are maintained as they always have been.

So existing packages continue along as they are. If the existing maintainers take specific actions to fix bugs or add features, that is their perogative. If they want to add people to the repo, that is up to them. If someone with their own vision for one of these packages creates their own version, they should go for it and see how it goes. This way (1) there is no disruption in how any existing package works or will continue to work and (2) we will gradually switch back to a decentralized way of managing these projects to the extent that new packages provide practical benefits over existing ones.

rupert · January 13, 2023, 1:46pm

I was maintainer of elm-community/typed-svg, I will now fork that as the-set/typed-svg. My thinking is that whilst typed-svg is useful, its also not the easiest thing to use. Someone could conceivably come up with a better SVG package that is also typed - some kind of DSL or better concept for dealing with the large size of SVG.

So there is no particular reason for typed-svg to be considered special, or the default option to pick here.

system · January 23, 2023, 1:47pm

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

Topic		Replies	Views
Revive deleted code of Elm packages Request Feedback	27	1732	February 23, 2023
Are the stdlib repos abandonware? Learn	12	770	October 3, 2023
A process for core library fixes and improvements Request Feedback	53	7178	December 19, 2021
Package collaboration workflow Request Feedback	10	1356	January 25, 2020
How can I contribute to a package? Learn	4	655	October 14, 2018

[ANNOUNCE] elm-community status changed to "sunset"

Related Topics