Model the process after Rust's RFC process

CONTRIBUTING.md

@@ -56,13 +56,18 @@ Proposing architectural changes
 ---
 
 Solana's architecture is described by markdown files in the `doc/` directory, currently maintained
-by @garious. Changing the architecture is a three step process:
+by @garious. To change the architecture, you'll need to at least propose a change with an RFC document,
+and create an issue to track its implementation. Here's the full process:
 
-1. Propose to a change to the architecture by creating a PR that adds a markdown file called a "wip-doc"
-   (meaning "work-in-progress document" and pronounced "whip dock") to the directory `doc/wip/`. Add
-   at least the maintainer of `doc/` as a reviewer.
-2. The PR being merged indicates your proposed change was accepted. The document will remain in `wip/`
-   while additional PRs are submitted to update the Solana reference design, which is the Rust-only
-   version of this codebase (no `--features` enabled). Be sure to update the wip-doc as the
-   implementation reveals the need for tweaks to the architecture.
-3. Once implemented, contact the maintainer of the `doc/` to integrate the wip-doc into `doc/`.
+1. Propose to a change to the architecture by creating a PR that adds a markdown document called an RFC
+   (standing for "request for comments") to the directory `rfcs/`. Add at least the maintainer of `doc/`
+   as a reviewer.
+2. The PR being merged indicates your proposed change was accepted and that the Solana maintainers
+   support your plan of attack. Next, create an issue to track its implementation and create a PR
+   that updates the RFC with a link to the issue. This link allows anyone to quickly check the
+   implementation status of any RFC.
+3. Submit PRs that implement the RFC. Be sure to reference the issue created above in your PR description.
+   Feel free to update the RFC as the implementation reveals the need for tweaks to the architecture,
+   but if you do, be sure to add the maintainer of `doc/` as a reviewer to your PR.
+4. Once the implementation is complete, close the issue. Depending on the scope of the RFC, the maintainer
+   of `doc/` may then create a separate ticket to integrate the RFC into `doc/`.

rfcs/0001-smart-contracts-engine.md

@@ -1,6 +1,6 @@
 # Smart Contracts Engine
  
-The goal of this document is to define a set of constraints for APIs and smart contracts runtime such that we can execute our contracts safely on massively parallel hardware such as a GPU.
+The goal of this RFC is to define a set of constraints for APIs and smart contracts runtime such that we can execute our contracts safely on massively parallel hardware such as a GPU.
 
 ## Definitions
 

rfcs/0002-consensus.md

@@ -1,6 +1,6 @@
 # Consensus
 
-The goal of this document is to define the consensus algorithm used in Solana.  This proposal covers a Proof of Stake (PoS) algorithm that leverages Proof of History (PoH).  PoH is a permissionless clock for blockchain that is available before consensus.  This PoS approach leverages PoH to make strong assumptions about time among partitions.
+The goal of this RFC is to define the consensus algorithm used in Solana.  This proposal covers a Proof of Stake (PoS) algorithm that leverages Proof of History (PoH).  PoH is a permissionless clock for blockchain that is available before consensus.  This PoS approach leverages PoH to make strong assumptions about time among partitions.
 
 
 ## Basic Design Idea

rfcs/0003-storage.md

@@ -1,6 +1,6 @@
 # Storage
 
-The goal of this document is to define a protocol for storing a very large ledger over a p2p network that is verified by solana validators.  At full capacity on a 1gbps network solana will generate 4 petabytes of data per year.  To prevent the network from centralizing around full nodes that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the network.
+The goal of this RFC is to define a protocol for storing a very large ledger over a p2p network that is verified by solana validators.  At full capacity on a 1gbps network solana will generate 4 petabytes of data per year.  To prevent the network from centralizing around full nodes that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the network.
 
 # Background
 

rfcs/0004-leader-rotation.md

@@ -1,6 +1,6 @@
 # Leader Rotation
 
-The goal of this document is to define how leader nodes are rotated in Solana, how rotation may cause forks to arise, and how the converges
+The goal of this RFC is to define how leader nodes are rotated in Solana, how rotation may cause forks to arise, and how the converges
 in response.
 
 ## Leader Seed Generation