Scope of elm-community?
rtfeldman opened this issue · comments
The README currently says elm-community is for two purposes:
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.
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:
- Should the scope of
elm-communitybe different from what the manifesto README currently states? - If so, what would be the pros and cons of that different scope?
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.
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.
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.
@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?
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. 😄
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.
Documentation about a recommended repo isn't going to go anywhere. It will end before it starts.
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.
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.
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.
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.
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.
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.
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.
@BrianHicks I deleted your post- Robin may have deleted it intentionally, so let's wait for them to reply before posting it (so as not to mis-represent anything)
Hi, yes, I deleted the post intentionally. I read the "Getting Involved" section of the README just after I posted, and that gave me a different perspective on things. A couple of things I wrote didn't make sense to me anymore, so I figured I delete the post and think about things some more.
FWIW: I've rewritten large chunks of the readme in the past, but there are some sections that are still from the infancy and old days of elm-community. It needs updating properly again, probably after we have resolved this.
Written in a somewhat piecemeal fashion after possibly one too many cups of coffee...
I gotta start off by saying I'm pretty biased... I live & work at a place called Acorn "Community" & I'm the tech/web guy for the Fellowship of Intentional "Communities" and the Federation of Egalitarian "Communities", so I've got a pretty loaded definition of "Community".
If someone asks me "what should Elm Community be about", I think "it should be about the people! About benefitting the entire Elm Community!". And what that means to me is helping to distribute the responsiblity/burden of package maintenance, trusting other members to make the right decisions w.r.t. the repos we maintain, providing input/feedback to questionable changes to other maintainer's repositories, writing guides or tutorials to help newbies/maintainers/developers, and working together to help make Elm be the best it can be :)
I think Community-Driven Documentation is an obvious exemplification of this. It was pretty off-putting when Evan said that guide.elm-lang.org was "his book", but owning & maintaining a discrete chapter would be OK with him. I'd much rather be part of a project where we all come together, compare our experiences, trials, & projects and come up with Docs that reflect this. And I think people would be less opposed to having other members maintain/update docs they have written(compared to repos they maintain). However, this seems to be one of the less active areas of the org. I still think together we could write a great book or tutorial for newbies though.
@rtfeldman's first point was that elm-community "provides a home for widely used packages that are no longer maintained", but I don't see where he gets "no longer maintained" from when reading the section of the Manifesto he quotes. To me, that section could also apply to packages where the current owner wants to take more of a backseat, or when the owner's level of involvement in Elm is variable or uncertain. Personally, I'd like to fork the abandoned elm-decimal & elm-integer libraries, and I see great benefit in moving these to Elm Community even though I could be actively maintaining a fork under my name. The biggest reason is to prevent furthur fracturing if I ever become less active(so you wouldn't have to use someoneElse/elm-decimal for Elm 0.17, prikhi/elm-decimal for Elm 0.18-0.20, and elm-community/elm-decimal for Elm 0.21+, and you wouldn't have to find the most active/developed version every time you bump Elm versions).
So I think we should totally keep the existing two purposes, possibly solidifying or expanding the definition of what packages are acceptable as Elm Community repositories(and I actually think that all packages should be allowed to become Elm Community packages).
I think Elm Community should also be about discussion & helping each other develop nicer APIs for our packages. Being a member of Elm Community makes it much easier to see discussion happening on every Elm Community repository compared to going through & starring/watching every single Elm Community repo, making it easier to contribute ideas when I have relevant experience, knowledge, or insights, & making it easier to see and review pending PRs.
Regard Elm Community as a place for "The Golden Path" repos, or a "Best Of Elm" list, I would be fine with it for the small amount of repos where there is truly a single best way, and if we don't ditch the point of being a place to share maintence of packages. But I think this would include a lot of discussion and decision-making before we could truly say "this is the best way to approach this problem", and members would have to be down to have those discussions & make those decisions.
When I first started w/ Elm, I actually steered clear of all the Elm Community repos, mostly because the READMEs for all the *-extra repos said something along the lines of "This package/API is highly experimental...". So it's hard for me to imagine Elm Community as being a place for only tried & true packages.
This section was off-topic, see #75.
This is getting long and I feel like I'm rambling a bit, so I'll just stop here for now...
For posterity, here's what I said when this came up on Slack:
I've thought of elm-community as helping to centralize maintenance of & discussion on packages, and not necessarily being the "golden path" of elm development, which seems to be what the Manifesto is saying as well(but maybe that's out-of-date? or maybe I missed something?).
For me, the benefit of elm-community packages is that I can walk away from being a maintainer and someone can easily step in - without having to notify all the users of my packages and without them having to look for alternatives or decide between however many forks pop up. And as a member, it's easier to see all the discussion, issues, & PRs happening on all the org's repos and maybe chime in if I have any relevant comments than it is to just star or watch individual repositories.
@prikhi, this explains the role of the assigned maintainer: https://github.com/elm-community/manifesto#the-role-of-a-maintainer
Generally, it is up to them to merge PRs. The exception is when they have not replied in several days and aren't responsive. See this issue for legacy info around this.
Edit: off-topic, see #75.