Moving projects off the org

[vmx]

I think only projects which are actively maintained (have a lead maintainer) should be under the official IPLD organisation. Other could be move e.g. to https://github.com/ipfs-shipyard.

Potential candidates:

• https://github.com/ipld/py-cid
• https://github.com/ipld/py-ipld-dag
• https://github.com/ipld/js-ipld-graph-builder

[Stebalien]

That significantly harms discoverability, I quite frequently go to one of our orgs wondering " do we have an implementation of X in Y language?". Can we not just put a big warning in the readme (or archive them)?

[mikeal]

I quite frequently go to one of our orgs wondering " do we have an implementation of X in Y language?".

It's totally reasonable for future implementations to be written by independent developers who don't want to put their project in this org. We probably need to build a more flexible list of implementations, maybe in the main IPLD README, in the long term anyway.

I think only projects which are actively maintained (have a lead maintainer) should be under the official IPLD organisation.

This is relevant ipfs/community#332

We need to figure out a better process for when things are in/out of org and how to call out soft deprecations.

[lanzafame]

Maybe something along the lines of Terraform Registry would be ideal, including the idea of 'verified' implementations. Another way could be something like an 'awesome-x' repo but has a cli or website integration similar to helm charts for search and 'installation' purposes.

[jbenet]

Repo membership in an org should not be denied because of lacking maintainers. It's a way to house and contribute the code into a more permanent/stable place than a single author's github account. It's a step forward in both long-term survival and discoverability.

How about modifying the repo description (on github) and the readme, to add highly visible "DEPRECATED" or "UNMAINTAINED" signals. These tend to work well across open source. could even suffix the repo `{-archived, -unmaintained, -deprecated}" or something, to really drive it home.

It's totally reasonable for future implementations to be written by independent developers who don't want to put their project in this org. We probably need to build a more flexible list of implementations, maybe in the main IPLD README, in the long term anyway.

Agree, like https://github.com/ipfs/ipfs#api-client-libraries

[mikeal]

@jbenet this seems like the right way forward right now.

In the future we'll need to worry about the perception that we are "blessing" one implementation over another, but that concern is far enough in the future that we should table it for the time being.