From 321f250d67d89d69f1c709364ff2da14f6b5c3d4 Mon Sep 17 00:00:00 2001 From: Bryan Newbold Date: Wed, 3 Jan 2018 12:56:19 +0100 Subject: document RFC process and add a template --- rfcs/README.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 rfcs/README.md (limited to 'rfcs/README.md') 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. + -- cgit v1.2.3