When and how do we let a project die?

[SelfDrivingCarp]

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:

• Cases that would cause us to not take a project over
• How/where we communicate to visitors to that project that we won't take it over
• Do we direct people toward/endorse alternatives to that project?

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).

[theckman]

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:

• https://github.com/istreamdata/orientgo #18 (github.com/istreamdata/orientgo)
  • Package has no external importers
  • Author moved on to a similar kind of project (cayley), so probably better to suggest it
• ReactiveX/RxGo #17 (github.com/ReactiveX/RxGo)
  • The project has little to no adoption, and it never reached a moment of API stability. Too early for us.
  • README says "This is an early project and your contributions will help shape its direction."
• wit.ai Client #11 (wit.ai API client)
  • There are two incomplete projects interacting with their API
  • Not much adoption of either projects, with the person who opened the help-request looking to be one of the few public consumers of this package.
• gads - Google Adwords API for Go #9 (github.com/emiddleton/gads)
  • "The AdWords API relies on SOAP and WSDL technologies to offer its services."
  • Only imports we could find were from forks of the project itself
  • From the issue, it sounds like the API itself is also a pretty quick moving target
• go-bindata #7 (github.com/go-bindata/go-bindata)
  • There is a fork being maintained by Kevin Burke; offered our help if he should ever need it
• buger/jsonparser #5 (github.com/buger/jsonparser)
  • Maintainer reappeared and merged critical bug fixes.

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.

[SelfDrivingCarp]

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.

[dylan-bourque]

I think the first 2 criteria should be:

1. In use by the community, i.e. imported by projects other than the one we're being asked to adopt.
2. The current or former owners/maintainers have abandoned it.

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.