1 files changed, 61 insertions, 0 deletions
diff --git a/rfcs/README.md b/rfcs/README.md
new file mode 100644
index 0000000..0b72646
--- /dev/null
+++ b/rfcs/README.md
@@ -0,0 +1,61 @@
+
+This folder (part of the `dat-docs` repository at
+https://github.com/datproject/dat-docs) contains a series of proposed (and
+eventually accepted) "Requests for Comment" (RFC) documents for the Dat
+Protocol and ecosystem.
+
+For now this process is as simple and informal; as the number of dat developers
+and users grows, it may become more formal. Inspirations for this process
+include:
+
+- [Bittorrent Enhancement Proposals (BEP)](http://bittorrent.org/beps/bep_0001.html)
+- [Rust RFC Process](https://github.com/rust-lang/rfcs)
+- [Python Enhancement Proposal](https://www.python.org/dev/peps/pep-0001/)
+
+
+## The Process
+
+TL;DR: write up an RFC
+
+* Fork this git repository
+* Copy `rfcs/template.md` to `text/0000-my-proposal.md` (don't chose the "next"
+  number, use zero; `my-proposal` should be a stub identifier for the proposal)
+* Fill in the RFC template. The more details you can fill in at the begining,
+  the more feedback reviewers can leave; on the other hand, the sooner you put
+  your ideas down in writing, the faster others can point out issues or related
+  efforts.
+* Submit a github pull request for discussion. The proposal will likely be
+  ammended based on review and comments. The PR will be tagged to indicate
+  RFC type and status.
+* Build consensus. This part of the process is not bounded in time, and will
+  likely involve both discussion on the PR comment thread and elsewhere (IRC,
+  etc).
+* Consider drafting or prototyping an implementation to demonstrate your
+  proposal and work out all the details. This step isn't necessary, however: a
+  proposer does not need to be a developer.
+* If consensus seems to have emerged (for or against the proposal), a team
+  member will assign an RFC number, update the status, and merge the PR.
+* Small tweaks (grammar, clarifications) to a merged RFC can take place as
+  regular github PRs; revisiting or significantly revising should take place as
+  a new RFC.
+
+RFCs should have a type:
+
+* **Standard** for technical changes to the protocol, on-disk formats, or
+  public APIs.
+* **Process** for formalizing community processes or other (technical or
+  non-technical) decisions. For example, a security vulnerability reporting
+  policy, a process for handling conflicts of interest, or procedures for
+  mentoring new developers.
+
+The status of an RFC can be:
+
+* **Draft**: writen up, open PR for discussion
+* **Active**: PR accepted; adopted or intended for implementation in mainline
+  libraries and clients as appropriate
+* **Closed**: PR was closed without merging; either consensus was against, a
+  decision was postponed, or the authors withdrew their proposal.
+* **Superseded**: a formerly "active" RFC has been made obsolete by a new
+  active RFC; the new RFC should specify specific old RFCs that it would
+  supersede.
+