RFC Process

[chuckadams]

Right now we have docs in https://github.com/fairpm/fair-protocol which go through a PR process, and that serves us pretty well for development, but it's not quite the same as a formal RFC process. Some of the key differences:

• The PR stream is very noisy and hard to follow in terms of discussion. Merged PRs aren't shown in the default browse UI, multiple updates over time mean multiple PRs, etc.
• Docs aren't necessarily normative: they could be informational, supplemental, or just out of date. RFCs would be the official source of truth, with a degree of rigor to them (such as voting) that I don't want to impose on docs as a whole.
• RFCs might cover different or even multiple areas, but should still live in one place with no one having to play "hunt the repo".

So with that, I'm going to propose rfc-0000 below, which I'll fill in as we discuss things (I'm choosing that naming convention because "RFC123" makes me think of an IETF RFC. Leading zeros are to make things sort nicely, and Four Digits Ought To Be Enough For Everyone (even the IETF is only now creeping up on RFC10000).

BTW, if anyone has a catchier acronym than "RFC", I'm all ears (I like Python's "PEP", but not a fan of PHP and Java's "PSR" and "JSR").

---

rfc-0000.md

rfc-0000 will define how RFC documents work. I'll edit this post to update this doc taking information from other "meta RFCs that I know of from various projects. They tend to define how an RFC is proposed, accepted, superseded, etc, as well as define terms like MUST and SHOULD and so forth.

Glossary

• RFC: Request For Comments

---