Why do this?
Questions for the community
I’m open to feedback and suggestions, including naming ideas for the org. If there’s enough interest, I’m happy to set it up and start maintaining the forks.
First question, the name of this github org? Second question, who wanna join this org ?
Is this approach acceptable from the Nim community’s perspective?
I think the general idea here of trying to maintain or patch libraries folks rely on is a good idea.
Are there concerns about redirecting Nimble packages to community-maintained forks?
I have some concerns about changing the url of nim-lang/packages depending on the scenario.
If supposing I use a stable (though maybe not "maintained") library I've assumed a level of trust from the original maintainer. If the source of this package changes without my knowing this trust feels broken. Particularly in a sense that given the decentralized nature of nimble and nim packages. One can switch to a hard fork by utilizing a full URL without nim-lang/packages NEEDING to change. I think for any package that is no longer active a good faith effort should be made to encourage original maintainers to "donate"" the source repo, for anything on github (which is most of the packages) this would make redirects more seamless, and following this we can make a change in nim-lang/packages.
If authors are entirely unreachable then I think more care should be given on a case-by-case basis whether a hard-fork should subsume a package name rather than just creating a new package (i.e. like pkg2).
I think the scenario I describe above is less murky if a package is completely deleted or unreachable which makes the original package name in nim-lang/packages less contestable.
Regarding a name for the org I think nim-community is available and the most clear.
Do you have examples of "important" libraries that are not maintained that would benefit from this treatment?
Is this approach acceptable from the Nim community’s perspective?
It honestly seems fine to me, the git repo for nim-lang/packages specifically states that having up-to-date packages is a requirement. The requirements section literally outlines "Non-compliant packages might be removed with no warning."
I think removing packages is a bit too extreme, but forking them and changing the URL to point elsewhere is fine enough actually.
Are there concerns about redirecting Nimble packages to community-maintained forks?
I think we need to establish a set of criteria for what exactly makes a package so "important" as to be community-maintained when abandoned, and nim developers should know about this when they submit new packages. (Put it in the requirements section of nim-lang/packages)
As @daylinmorgan outlined, you do risk breaking user trust when you switch the source of a package, so we need to establish a transparent process for turning packages into community-maintained ones. We need to be able to take advice from users, we need to give time for the original package maintainers to respond with any objections (if they have any)
With regards to technical concerns, I have very little. This isn't very different from just releasing new package updates. There are probably going to be users out there who have configured their dependencies to always use the latest version of any given package, and so, I am worried that some software might secretly break because of it. But that will always happen, and the only thing we can do is to encourage users to depend on specific package versions or use lockfiles.
Would it make sense to treat this as a semi-official “community maintenance” org?
Yeah, that's basically what it is. The nimble package repository is hosted on the official GitHub organization, and so the community maintenance org would be at least semi-official, since packages can be re-pointed to the community maintenance org.
+1 to @daylinmorgan's suggestion about creating new packages instead of switching the URL (pkg2 instead of changing the URL of pkg).
We could also just use a prefix (pkg-community or pkg-public), I believe in this option because it would preserve user trust and also let the original maintainers keep control of their package should they return.
Though, we might have to introduce a way to mark a package as abandoned and signal to users where the new, community-maintained package is. I don't know if tags and package aliases are flexible enough for this (I don't think they are)
my intension is make the repo into a well maintain status,I'll not touch nimble and any other package manager tool, so change package installation dir is not on the list, I created the org named as nim-community
and here is the first issue https://github.com/nim-community/tools/issues/1