This PR clarifies the CID spec governance by pointing at IPIP process from ipfs/specs repo.
I suggest reusing IPIP because don't have anything better, and something is better than no process at all, but other ideas are welcome.
Rationale
CID specification is extremely important for IPFS ecosystem, and we need a clear policy how spec change proposals (namely, proposing new versions, like https://github.com/multiformats/cid/pull/49) should be handled now and in the future.
We need to have a policy for CID and other Mutliformats, but since CID is the only one that has the concept of versions, let's scope this to CID repo for now.
Why IPIP?
The IPIP template provides prompts around key areas that need to be filled, which ensures the bare minimum structure and context that gets everyone up-to-speed, including a summary of relevant prior discussions.
This allows implementers and the wider IPFS community to evaluate, provide more meaningful feedback, and reach a rough consensus around a proposal.
This PR clarifies the CID spec governance by pointing at IPIP process from ipfs/specs repo.
I suggest reusing IPIP because don't have anything better, and something is better than no process at all, but other ideas are welcome.
Rationale
CID specification is extremely important for IPFS ecosystem, and we need a clear policy how spec change proposals (namely, proposing new versions, like https://github.com/multiformats/cid/pull/49) should be handled now and in the future.
We need to have a policy for CID and other Mutliformats, but since CID is the only one that has the concept of versions, let's scope this to CID repo for now.
Why IPIP?
The IPIP template provides prompts around key areas that need to be filled, which ensures the bare minimum structure and context that gets everyone up-to-speed, including a summary of relevant prior discussions.
This allows implementers and the wider IPFS community to evaluate, provide more meaningful feedback, and reach a rough consensus around a proposal.