Repository navigation
Moving projects off the org #51
Description
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:
Activity
Stebalien commentedon Oct 1, 2018
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 commentedon Oct 1, 2018
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.
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 commentedon Oct 2, 2018
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 commentedon Oct 17, 2018
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.
Agree, like https://github.com/ipfs/ipfs#api-client-libraries
mikeal commentedon Oct 17, 2018
@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.
Merge pull request #51 from Stebalien/feat/car
Merge pull request #51 from ipld/fix/49