The _Reliable Specs_ Initiative

[daviddias]

I'm creating this initiative following #214 in order to move all our specs from or to

This will be a huge spec in our documentation efforts and also a big aid to the core implementation teams to have a shared resource they can rely on.

If/when #214 gets merged, the plan is to run a call for volunteers to tackle each spec individually while I (with the help of others) can play the role of the top level maintainer.

[mikeal]

BTW, you may want to look at the staging system we did for IPLD specs https://github.com/ipld/specs#specification-document-status

We separated specs into two parallel tracks called “Prescriptive” and “Descriptive.” This was necessary because we have specifications for things we are currently implementing and want others to implement as well as specifications we are writing to backfill existing behavior that we can’t actually change. The process for changes to each track, and the meaning of things like “draft,” are substantially different so we found it helpful to split them apart.

[daviddias]

Linking here the good notes from @Stebalien and @b5 on using an Rust inspired model (RFC + Spec)

• Repo reorg, cleaning up the spider webs #214 (comment)
• Repo reorg, cleaning up the spider webs #214 (comment)

The next TODO on this initiative is to create a PR that describes that Rust inspired model (and given that libp2p also adopted it, also use it as a reference) and continue the conversation there.

[lidel]

Continued in #286