Scope of elm-community?

[rtfeldman]

The README currently says elm-community is for two purposes:

1. Providing a home for widely used packages that are no longer maintained

It sometimes happens that packages which are widely used need a bit of maintenance...Normally, package authors will deal with that themselves, of course, possibly with the help of pull requests from interested community members etc. However, sometimes package authors may not be available, for one reason or another, and other work can be blocked until the maintenance is performed...In those cases, elm-community can provide a home for a fork, and the necessary work to maintain the package.

2. Community-Driven Documentation

Elm has great documentation, but there is always room for more, and room for documentation oriented towards particular audiences...So, this can serve as a central point for that.

There have been discussions about whether the scope of elm-community should be different from this, and I'd like to centralize them here.

So:

1. Should the scope of elm-community be different from what the manifesto README currently states?
2. If so, what would be the pros and cons of that different scope?

[BrianHicks]

I don't think elm-community should grow in scope. If a package is maintained by an individual, that's an indicator of ownership. It can also be an indicator of quality (for example, I'm likely to trust @rtfeldman's packages more than an author whose work I have not previously encountered.)

Random idea: trust has technical components as well; the package site could include authorship/maintainership info beyond the repo owner at some point down the road.

The counterpoint here is mentorship within elm-community repos. It seems like a valid point, but consider that if we have to create processes for mentorship anyway, we may as well leave the repos where they stand. It doesn't break dependency trees to do so, and part of the process can be ensuring write access to those who need it, et cetera. If the original maintainer disappears, there's already a process for moving a repo to elm-community.

[eeue56]

I don't think elm-community should grow in scope. If a package is maintained by an individual, that's an indicator of ownership. It can also be an indicator of quality (for example, I'm likely to trust @rtfeldman's packages more than an author whose work I have not previously encountered.)

No, being owned by an individual shows that there is no "defacto" approach. Most of all, elm-community packages show that they are defacto package. For example, elm-test. The existence of elm-community/elm-test means that others don't need to approve of a given approach. http was moved to elm-lang because people felt that evancz/elm-http meant that it wasn't "official" in some sense of the word.

I do think that packages shouldn't just be the dead or dying. They should be those which are used heavily and are the main approach. For example, elm-webpack-loader. I could've maintained it as eeue56, but it is the recommended approach, and so it became elm-community/elm-webpack-loader. The same thing goes for elm-test. It could have been eeue56/elm-test, and it was, for a while (0.17 alpha). But I moved it to elm-community in order signify "this is the ONE way to do it".

When there are repos which are so central to the community, it is important there is shared ownership with community. A package in the hands of elm-community is safer than an isolated repo: if Brian disappeared, elm-benchmark would be inaccessible for everyone to use. Likewise, with repos like create-elm-app, if the owner disappeared, there would be countless numbers of people trying to install it, only to find that it is out of date or does not work.

A community project is one that has been embraced by people all over, and worked on together to make it better. When it comes to production code base, there has been at least two times when I have managed to prevent the Elm ecosystem collapsing from having access to repos while other people were AFK or asleep, for example, the renaming of elm-lazy-list. When it comes to the "one solution", mentoring and code-reviews are a vital part of that. For example, how should API X look, etc.

[rtfeldman]

I appreciate the value in "there is one way to do it," but I think we can do better than curating such a list by moving repositories into the elm-community GitHub organization.

One problem with that approach is that people come out with new packages that are better than existing ones. For example, I recommend abadi199/datetimepicker to people even though elm-community/elm-datepicker already exists. Should I not do that, just because elm-datepicker is in elm-community? Should we ask Abadi to move his package into elm-community, replacing elm-datepicker? Neither option sounds reasonable to me.

Recommended packages will change over time as people innovate, which makes me conclude that the elm-community organization can't be a long-term "one-stop shop for recommended packages" - shuffling repositories in and out of it as recommendations change would be 😱.

Here's what I propose:

Curated Recommendation List

In the spirit of "community-driven documentation" and faq.elm-community.org we publish a list of community-recommended packages for solving particular problems.

The rule for making it onto the list would be that someone opens an issue proposing a change (addition, removal, or swap) to the list, and then maintainers discuss pros and cons of the proposed change before requesting a PR.

I think this would be better than using the elm-community organization for this purpose, as we could link beginners to a single page which would represent a treasure trove of high quality packages, with descriptions. This would be even better than browsing elm-community/repositories, which won't lead people to things like Abadi's awesome date picker.

[BrianHicks]

@eeue56 this is a really reasonable thing to point out. We obviously don't want to cause outages or split versions between an old (evancz/elm-http) and new (elm-lang/http) repos. I think this is part of the process solution. Mentorship is really important; I think it could alleviate the "disappearing maintainer" problem somewhat.

For the record, if I disappear please feel free to fork my repos and do whatever you like with 'em. If that happens I'll probably be permanently gone in some way, but I have failsafes in place to let people know if that happens. :)

@rtfeldman I think this is a great idea! I also think it could cause problems and divisions, politically. If we want only one recommendation per domain, there's going to have to be a fair amount of editorializing. Like which is the best date-extra package? We'd have to be very careful to treat everyone equitably.

The other approach is just including everything. But then it's just elm-community/awesome-elm. I don't think that's what you mean, is it?

[rtfeldman]

If we want only one recommendation per domain, there's going to have to be a fair amount of editorializing.

Yep, but that's true regardless of whether the recommendations are packages in an organization versus links in a curated list. 😄

[BrianHicks]

Mmm, I could have communicated that better. What I mean is: it's really easy to recommend a package as the best when there's only one package. When there are two or more and we only recommend one, we have to change away. That could cause some tension. But really, this is just something to look out for.

This makes a lot of sense to me. I think it fits really nicely under the "community-driven documentation" portion of the manifesto.

[eeue56]

Documentation about a recommended repo isn't going to go anywhere. It will end before it starts.

[eeue56]

Recommended packages will change over time as people innovate, which makes me conclude that the elm-community organization can't be a long-term "one-stop shop for recommended packages" - shuffling repositories in and out of it as recommendations change would be 😱.

This is true of some things. For example, datepicker APIs. People need different things. I don't believe that there is "one way" to do a datepicker nicely. It's also not something that requires a lot of community input. It's not the same as create-elm-app.

In order to make a new Elm project, there should be one way to do it. In the land of JS, the number of choices on how to start a project is a documented issue. Yo generators, all kinds of custom scripts, create-react-app. It is in the interest of the community to have a single approach to making a basic Elm project. Just like how there is benefit to having a single testing framework. This is not the same as a non-specific package.

[Chadtech]

I really appreciate this discussion happening. In my short time in this github group, Ive found it's mission confusing. It's pleasing to see resolution on this topic.

I'm a bit critical of @rtfeldman 's proposal. I bet a group dedicated to curating a list of good packages would effectively be a discussion group. I bet such a group would have difficulty reaching conclusion, and the conclusions it does reach would have less influence. @rtfeldman pointed out that editorializing will happen no matter what, but maybe editorializing will happen best in an entity that isnt self-aware as an editorial organization.

Having actual repos, and actually performing maintenance, gives elm-community credibility. The way its currently set up makes it more effective at reaching good conclusions. There are official maintainers, who are de facto arbiters on conclusion. Having members and maintainers creates a natural membership filter against people more interested in discussion than code bases, and sorts people to the code bases they are most interested in.

Being a central place where people collaborate on community repos naturally makes it a pretty-good curated list. There will be holes of course, like abadi199/datetimepicker, but thats okay. There would missing pieces in a deliberately curated list too. Elm-community can bring coherence, mentorship, and collaboration to the wider elm community, even if it doesnt own all of the best repos.

For those reasons I think status quo might be best, especially if this mission stuff gets resolved.

[rtfeldman]

maybe editorializing will happen best in an entity that isnt self-aware as an editorial organization

Intuitively, the opposite would seem true. Why would less self-awareness yield a better outcome? 🤔

I bet such a group would have difficulty reaching conclusion, and the conclusions it does reach would have less influence.

Suppose we changed the manifesto to say that part of the organization's purpose is to be a home for already-maintained repos that we decide are sufficiently high quality. Then suppose someone publishes a new repo and requests moving it into the elm-community organization.

How does the conversation about whether this repo is "sufficiently high-quality" to be moved over go any differently than a conversation about whether that repo is "sufficiently high-quality" to be included on the list?

Being a central place where people collaborate on community repos naturally makes it a pretty-good curated list.

If the goal is to solve the problem of establishing the One Recommended Way, why settle for pretty good when we could solve it properly? 😉

It's a fair point that "one way to do it" makes less sense for datepickers than it does for creating a new Elm app. But what about mdgriffith/elm-style-animation, NoRedInk/elm-decode-pipeline, and rtfeldman/elm-css? Each of those have alternative ways to do them, yet I see people recommend those solutions more often than any alternative.

Having a curated list could help people find those packages. Short of moving those and 100% of other recommended packages into the elm-community organization, we will always be telling people "here are the recommended things, in addition to what's in elm-community" in an ad-hoc way. It can't solve the problem over the long term.

I'm having a hard time seeing why using the organization this way would be a better solution to the problem than a list. It seems like more work in exchange for a less complete solution. If we're afraid to discuss what goes on the list, that suggests we aren't yet confident what the One Way to Do It is.

[Chadtech]

Sorry, maybe I was too out-there in my post; I didnt really connect that well with my own views or the core questions in this issue.

I basically agree with Noah. While maintaining packages is listed as a purpose of this group, it doesnt really make sense to me why dead or dying ones would be the only sort of package elm-community adopts. I read what Evan said about reputation. I thought was that really interesting, but I didnt ultimately see how that connects. More fundamentally, the readme says this group is a middle ground between elm-lang/ packages, and individual packages. I read that as saying the purpose of such is to facilitate common practices. @rtfeldman, you made that point about abadi119's repo being the best, but literally owning all the singularly best repos isnt necessary towards that purpose of facilitating common practices.

Why would less self-awareness yield a better outcome?

How does the conversation about whether this repo is "sufficiently high-quality" to be moved over go any differently than a conversation about whether that repo is "sufficiently high-quality" to be included on the list?

Well it would be a different group, with a different definition. So I think the conversations would naturally go differently. Like I said, a group that curates a list of good practices just sounds like a discussion group. Elm-community is not a discussion group. I dont think the question in front of elm-community today is whether any repo is "sufficiently high-quality", but it would certainly be the question in front of a group meant to curate the best repos.

A group that just curates a list, doesnt do the sort of thing that I think Noah and I would like this group to do. I think Noah and I would like to help the formation of good practices in that middle ground between core packages and individual packages; not just list the existing good practices.

[mgold]

If the goal is to solve the problem of establishing the One Recommended Way, why settle for pretty good when we could solve it properly?

Some projects, like testing frameworks, work best when there is only one of them and anyone so inclined can jump in and start contributing. This creates a community standard, avoid wheel reinvention, and keeps that standard open.

Other projects, like datepickers, need to have competing ideas and implementations so that we can figure out what works best. If we ever made a "works for everyone" datepicker, it would be complex enough that someone would create simpler, streamlined version as an alternative.

So, I think it really depends on the project. I think we should document what's already true, namely that elm-community is more than life support for abandoned packages but instead tries to produce standard, best-of-breed projects. But not all project areas lend themselves to such.

[avh4]

Providing a home for widely used packages that are no longer maintained

Based on the current packages, I think this statement should be expanded to include packages where the original author can't or doesn't want to be the full-time maintainer. That includes a lot more situations than "abandoned packages". It can even include situations where the original author still actively uses and contributes to the package, but doesn't want to be the full-time maintainer.

[eeue56]

Agree with mgold and av, these are also my thoughts. In my mind, these also include popular packages that need further direction. When I referred to mentoring on the Slack recently, I was thinking of situations as av describes. This is not out of scope of what elm-community is already doing and has done in the past. It just isn't documented.