-
Notifications
You must be signed in to change notification settings - Fork 3
When and how do we let a project die? #23
Comments
Thanks for raising this. This is something I've been noodling for a little bit, in terms of a set of initial ideas to seed a conversation. Before trying to talk to the points here, there were a few projects we declined so far for a few different reasons:
So now past that wall of text, a common pattern there looks to be projects that may be on the "experimental" side of things. Where either the project's APIs are still under-development, or maybe there's no visible usage of the package in the ecosystem. There are other packages we decided not to pick up, and offered to revisit if the person raising the issue was willing to invest the time to round-off the project and gain some users. I am 👍 on not taking on projects in specialized areas, like being deep in cryptography. I like the idea of a list of candidates. I had been thinking we'd keep the GitHub issues open until we can pick up the project, but the idea of a list feels a bit better to me. |
I'll be happy to create a PR for the website or a markdown-in-github document to concisely convey the common reasons once there's been more discussion or silence on this issue. |
I think the first 2 criteria should be:
All of the examples @theckman gave fail one or both of these. The exception would be something that we think has legs but isn't done/ready yet so we take it on because the current owner can't or won't finish it. |
Sooner or later we'll receive a request to take over a project that we probably shouldn't. Maybe there really are better alternatives that are maintained. Maybe the code is too much of a mess. Maybe none of the current gofrs contributors have the expertise (e.g. deep crypto). Maybe there are active maintainers but they're not addressing the requestor's specific issues.
We should have a living document that addresses:
Some thoughts:
It might be a bad idea to accept a project when only one contributor is willing to take it on. If that person is no longer willing/able to maintain it risks being orphaned by gofrs which would erode trust.
Maybe we maintain a page similar to awesome-go of seemingly viable alternatives to something that we've chosen not to maintain (yet).
The text was updated successfully, but these errors were encountered: