A process for core library fixes and improvements

Request Feedback
6

Hello, long time lurker here.

I think the hot/cold approach sounds nice, but also requires a lot of thought by Evan before it could be applied by him, and it would require him to continuously invest time adding/removing access to elm/* repos.

So I wanted to post this proposal that could “[work] completely independently and asynchronously to Evan”.

PROPOSAL 2: Fork core official packages.

The organization elm-explorations (description: “Packages that may one day be in @elm-lang”) is allowed publish Elm packages with kernel code written in JS. It has no public member list, but I assume that Evan already trusts the members there, so no new list of “maintainers” or “janitors” would need to be gathered from scratch - it could be extended though.

Use cases (as listed in the first post by @janiczek)

  1. If bug fixes do not (yet) land in an offical package, it could be forked and use the official version in its name.
    E.g. elm-explorations/parser-1.1.0-fixes or elm-community/elm-parser-1.1-fixes.
    Confusing might be that such a package would always start with a version number 1.0.0 unrelated to the official one (and also stay at this major version number). But the name of the package should make clear which official package it improves.
    Whenever the official package changes, existing forks must be marked as deprecated and the repository is archived.
    If the ofificial package changes in another way and introduces a new version number without the fixes, the fixes could be applied again to a new fork. This would only require work by the community, and not from Evan.
    If it is decided that the patched community fork should introduce a changed API, then I think the existing fork should be archived and the second use case should be followed.

  2. For explorations, a fork of the official package can be created.
    Something like the optimizations to elm/core as mentioned in the first post could be published as elm-explorations/elm-core-1.0.5-performance-dict-approach1 or under an unrelated name like stylish-elephants. The latter would decrease visiblity of the package and make it harder to find, but maybe that is also a good thing - at least it was a good idea for elm-ui.

In both cases, a maintainer could create a PR against the official repository and Evan could decide if he wants to merge it. And there would (hopefully) be no pressure to look into it soon and no constant nagging.
Also the code could already be used by community members and prove its usefulness, which might reduce the time Evan needs to decide if a change is a good idea for the official package, too.
If Evan should be no longer interested in continuing work on an official package, that one could be marked as deprecated and direct users towards the community/exploration fork instead.

The biggest threat that I see with this proposal is fragmentation and being confusing to new Elm users. But I think at least the risk of fragmentation could be reduced with documentation and discipline and quickly (and reliably) marking the community forks as deprecated.

Another thing: I think it would be great if Evan would allow the organization elm-community (description: “Unofficial group for shared work on Elm packages and documentation”) to also publish packages with JS kernel code.
Then bugfixes for official packages could be published there and elm-explorations could be used solely for cool new experiments.

The manifesto of elm-community already says
“It sometimes happens that packages which are widely used need a bit of maintenance […] and other work can be blocked until the maintenance is performed. […] elm-community can provide a home for a fork, and the necessary work to maintain the package.”

I assume it might be hard for Evan to give someone extensive rights inside the elm organization for a huge number of good reasons. But the entry barrier to elm-exploration and elm-community might be lower - especially as they are not advertized as being part of the official language or an officially-sanctioned package.

Edit: I used the word “core” misleadingly before, I now changed it to “official” to indicate that I don’t only mean the elm/core package, but elm/* in general. Also I now always use “package” instead of “library”.

3 Likes