From 631d8d035468fcad8c45893aba2f62ece33c7530 Mon Sep 17 00:00:00 2001
From: Tim Beiko <timbeiko@Tims-MacBook-Pro.local>
Date: Tue, 9 Apr 2019 10:57:12 -0400
Subject: [PATCH 1/5] First draft of Core EIPs Process

---
 index.html   |  4 ++--
 process.html | 40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 2 deletions(-)
 create mode 100644 process.html

diff --git a/index.html b/index.html
index 079dd0922d5c8c..f459c8e8a1a0a5 100644
--- a/index.html
+++ b/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. For more information on the EIPs process, see <a href="{{"process"|relative_url}}">Process</a> ({{site.pages|where:"type","Process"|size}}).</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>. </p> 
 
 <h2>EIP status terms</h2>
 <ul>
diff --git a/process.html b/process.html
new file mode 100644
index 00000000000000..0eeb56eb429f14
--- /dev/null
+++ b/process.html
@@ -0,0 +1,40 @@
+---
+layout: default
+title: EIPs Process
+---
+
+<h1 class="page-heading">EIPs Process</h1>
+
+<p>While the technical requirements for EIPs are well explained in <a href="EIPS/eip-1">EIP-1</a>, the EIPs process also includes a fair bit of coordination. This page aims to describe this more ad-hoc, "rough-consensus"-driven part of the EIPs process and assumes familiarity with the contents of <a href="EIPS/eip-1">EIP-1</a>.</p>
+
+<h2>EIP definition</h2>
+
+<p>In <a href="EIPS/eip-1">EIP-1</a>, an EIP is defined 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 standardied will inform which type or track an EIP belongs to.</p>
+
+<h2>Shepherding an EIP</h2>
+
+<p>Once you have written an EIP, it is your role to sheperd it through from a Draft to its final stage. The stages your EIP will go through depends on whether it is a Core EIP or not.</p>
+
+<h3>Core EIPs</h3>
+
+<p>Once the EIP has been merged as a Draft, Core EIPs need to be implemented by at least 3 clients to be considered Accepted. This implies that for a Core EIP to be succesful, you will need to either provide the technical 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 (1) discuss the technical merits of an EIP, (2) gauge whether other client implementers will be implementing an EIP and (3) coordinate EIP implementation for network upgrades.</p>
+
+<p>The outcome of these calls is generally a "rough consensus" around what EIPs should or shouldn't be included, as well as what EIPs may be too contentious to make a decision about. The "rough consensus" often rests on the assumption 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 formal ways to address these, often end up entangled in these issues. This puts the burden on client implementers to try and gauge community sentiment across several platforms, which hinders the technical coordination function of EIPs and AllCoreDevs calls.</p>
+
+<p>While there are no formal mechanisms today 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. If you are sheperding an EIP, one way 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>
\ No newline at end of file

From 38b0bc1d5f6420c629d006ae8c0c506395052789 Mon Sep 17 00:00:00 2001
From: Tim Beiko <timbeiko@Tims-MacBook-Pro.local>
Date: Wed, 10 Apr 2019 15:33:12 -0400
Subject: [PATCH 2/5] Text changes

---
 process.html | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/process.html b/process.html
index 0eeb56eb429f14..61b9163c41f63e 100644
--- a/process.html
+++ b/process.html
@@ -5,25 +5,27 @@
 
 <h1 class="page-heading">EIPs Process</h1>
 
-<p>While the technical requirements for EIPs are well explained in <a href="EIPS/eip-1">EIP-1</a>, the EIPs process also includes a fair bit of coordination. This page aims to describe this more ad-hoc, "rough-consensus"-driven part of the EIPs process and assumes familiarity with the contents of <a href="EIPS/eip-1">EIP-1</a>.</p>
+<p>This page describes coordination bits related to the EIPs process. For technical requirements, see <a href="EIPS/eip-1">EIP1</a>.  This page will assume familiarity with those requirements. </p>
 
 <h2>EIP definition</h2>
 
-<p>In <a href="EIPS/eip-1">EIP-1</a>, an EIP is defined 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 standardied will inform which type or track an EIP belongs to.</p>
+<p><a href="EIPS/eip-1">EIP1</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">EIP1</a> define Core EIPs as "improvements requiring a consensus fork (e.g. [EIP5], [EIP101]), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP90], and the miner/node strategy changes 2, 3, and 4 of [EIP86])". 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 sheperd it through from a Draft to its final stage. The stages your EIP will go through depends on whether it is a Core EIP or not.</p>
+<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 the EIP has been merged as a Draft, Core EIPs need to be implemented by at least 3 clients to be considered Accepted. This implies that for a Core EIP to be succesful, you will need to either provide the technical implementation for clients, or convince clients to implement your EIP.</p>
+<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 (1) discuss the technical merits of an EIP, (2) gauge whether other client implementers will be implementing an EIP and (3) coordinate EIP implementation for network upgrades.</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>The outcome of these calls is generally a "rough consensus" around what EIPs should or shouldn't be included, as well as what EIPs may be too contentious to make a decision about. The "rough consensus" often rests on the assumption 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>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>
 
@@ -35,6 +37,8 @@ <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 formal ways to address these, often end up entangled in these issues. This puts the burden on client implementers to try and gauge community sentiment across several platforms, which hinders the technical coordination function of EIPs and AllCoreDevs calls.</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>While there are no formal mechanisms today 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. If you are sheperding an EIP, one way 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>
\ No newline at end of file
+<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>

From 28a78765db509ea72498290b5226f8b53079d521 Mon Sep 17 00:00:00 2001
From: Tim Beiko <timbeiko@Tims-MacBook-Pro.local>
Date: Tue, 23 Apr 2019 14:26:06 -0400
Subject: [PATCH 3/5] Final changes

---
 Gemfile.lock | 2 +-
 index.html   | 4 ++--
 process.html | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index bc94a2e3c348ab..697bd2383a67e1 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -266,4 +266,4 @@ DEPENDENCIES
   tzinfo-data
 
 BUNDLED WITH
-   1.16.1
+   2.0.1
diff --git a/index.html b/index.html
index f459c8e8a1a0a5..87066f88ca0502 100644
--- a/index.html
+++ b/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. For more information on the EIPs process, see <a href="{{"process"|relative_url}}">Process</a> ({{site.pages|where:"type","Process"|size}}).</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>
diff --git a/process.html b/process.html
index 61b9163c41f63e..208e669a67189c 100644
--- a/process.html
+++ b/process.html
@@ -5,13 +5,13 @@
 
 <h1 class="page-heading">EIPs Process</h1>
 
-<p>This page describes coordination bits related to the EIPs process. For technical requirements, see <a href="EIPS/eip-1">EIP1</a>.  This page will assume familiarity with those requirements. </p>
+<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">EIP1</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><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">EIP1</a> define Core EIPs as "improvements requiring a consensus fork (e.g. [EIP5], [EIP101]), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP90], and the miner/node strategy changes 2, 3, and 4 of [EIP86])". Non-Core EIPs represent any EIP that does not fall within the Core category.</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="EIPS/eip-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>
 

From 5e3f56f56c67bae3aa62c860c83ea79ad3f22c9d Mon Sep 17 00:00:00 2001
From: Tim Beiko <t.beiko23@gmail.com>
Date: Tue, 23 Apr 2019 16:56:51 -0400
Subject: [PATCH 4/5] Update Gemfile.lock

---
 Gemfile.lock | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile.lock b/Gemfile.lock
index 697bd2383a67e1..bc94a2e3c348ab 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -266,4 +266,4 @@ DEPENDENCIES
   tzinfo-data
 
 BUNDLED WITH
-   2.0.1
+   1.16.1

From d38dc29aa9e45ff54e297a87206f8b39c70a67c2 Mon Sep 17 00:00:00 2001
From: Tim Beiko <t.beiko23@gmail.com>
Date: Tue, 23 Apr 2019 17:03:55 -0400
Subject: [PATCH 5/5] Update process.html

---
 process.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/process.html b/process.html
index 208e669a67189c..d4c9ad4bb7c239 100644
--- a/process.html
+++ b/process.html
@@ -11,7 +11,7 @@ <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="EIPS/eip-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>
+<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>