Add a Process page to eips.ethereum.org

index.html

@@ -7,10 +7,10 @@ <h1 class="page-heading">EIPs
   <a href="https://gitter.im/ethereum/EIPs?utm_source=badge&amp;utm_medium=badge&amp;utm_campaign=pr-badge"><img src="https://badges.gitter.im/Join%20Chat.svg" alt="Gitter"></a>
   <a href="/last-call.xml"><img src="https://img.shields.io/badge/rss-Last Calls-red.svg" alt="RSS"></a>
 </h1>
-<p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.</p>
+<p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. </p> 
 
 <h2>Contributing</h2>
-<p>First review <a href="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <a href="https://github.com/ethereum/EIPs/blob/master/eip-X.md">template EIP here</a>. Then submit a Pull Request to Ethereum's <a href="https://github.com/ethereum/EIPs">EIPs repository</a>.</p>
+<p>First review <a href="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <a href="https://github.com/ethereum/EIPs/blob/master/eip-X.md">template EIP here</a>. Then submit a Pull Request to Ethereum's <a href="https://github.com/ethereum/EIPs">EIPs repository</a>. For more information on the EIPs process, see <a href="{{"process"|relative_url}}">Process</a>.</p> 
 
 <h2>EIP status terms</h2>
 <ul>

process.html

@@ -0,0 +1,44 @@
+---
+layout: default
+title: EIPs Process
+---
+
+<h1 class="page-heading">EIPs Process</h1>
+
+<p>This page describes the coordination bits related to the EIPs process. For technical requirements, see <a href="EIPS/eip-1">EIP-1</a>.  This page will assume familiarity with those requirements. </p>
+
+<h2>EIP definition</h2>
+
+<p><a href="EIPS/eip-1">EIP-1</a> defines an EIP as "a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment". One way to think of EIPs is as a standardization process within Ethereum. What is being standardized will inform which type or track an EIP belongs to.</p>
+
+<p>There are several categories of EIPs, but for the purpose of the EIP process, the most important distinction is between Core and non-Core EIPs. <a href="EIPS/eip-1">EIP-1</a> define Core EIPs as "improvements requiring a consensus fork (e.g. <a href="EIPS/eip-5">EIP-5</a>, <a href="EIPS/eip-101">EIP-101</a>), as well as changes that are not necessarily consensus critical but may be relevant to <a href="https://github.com/ethereum/pm">“core dev” discussions </a> (for example, <a href="https://github.com/ethereum/EIPs/issues/90">EIP-90</a>, and the miner/node strategy changes 2, 3, and 4 of <a href="EIPS/eip-86">EIP-86</a>)". Non-Core EIPs represent any EIP that does not fall within the Core category.</p>
+
+<h2>Shepherding an EIP</h2>
+
+<p>Once you have written an EIP, it is your role to shepherd it through the EIP workflow, from a WIP to its Final stage. The stages an EIP will go through depend on whether it is a Core EIP or not.</p> 
+
+<h3>Core EIPs</h3>
+
+<p>Once they have been merged as a Draft, Core EIPs need to be implemented by at least 3 clients to be considered Accepted. Hence, for a Core EIP to be successful, you you will need to  provide the EIP's implementation for clients, or convince clients to implement your EIP.</p>
+
+<p>The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an <a href="https://github.com/ethereum/pm/issues">AllCoreDevs agenda Github Issue.</a></p>
+
+<p>The AllCoreDevs call serve as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.</p>
+
+<p>These calls generally result in a "rough consensus" around what EIPs should be implemented. This "rough consensus" rests on the assumptions that EIPs are not contentious enough to cause a network split and that they are technically sound. For a description of how consensus is reached within the broader Ethereum community, see the "Community Consensus" section below.</p>
+
+<p>Once an EIP has been implemented in a network upgrade, it becomes Final.</p>
+
+<h3>Non-Core EIPs</h3>
+
+<p>Once the EIP has been merged as a draft, it must be implemented to move to Last Call. If no objections to or issues with the EIP are brought up while it is in last call, it will then be considered Final.</p>
+
+<h2>Community Consensus</h2>
+
+<p>Some EIPs may be technically sound but contentious for other reasons within the Ethereum community. For these EIPs, the biggest challenge is to build community consensus.</p>
+
+<p>The EIPs process and AllCoreDevs call were not designed to address non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls.</p>
+
+<p>While there are no formal mechanisms to build community consensus around an EIP, it is worth highlighting that each EIP should have an <a href="https://ethereum-magicians.org/">Ethereum Magicians</a> discussion thread.</p>
+
+<p>If you are shepherding an EIP, you can make the process of building community consensus easier is by making sure that the Ethereum Magicians thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.</p>