1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
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 markdown file, submit a github PR, revise per review,
community either accepts (merges PR) or does not (closes PR).
* 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.
|
