Updates to EIP-1 to reduce the dependence on ACD for Acceptance

EIPS/eip-1.md

@@ -17,14 +17,14 @@ EIP stands for Ethereum Improvement Proposal. An EIP is a design document provid
 
 We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
 
-For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
+For Ethereum implementers, EIPs are a convenient reference during implementation. Ideally each Ethereum implementation would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
 
 ## EIP Types
 
 There are three types of EIP:
 
 - A **Standard Track EIP** describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories. Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification].
-  - **Core** - 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]).
+  - **Core** - improvements requiring a consensus fork (e.g. [EIP5], [EIP101]), as well as changes that are not necessarily consensus critical but may be relevant to Ethereum implementers (for example, [EIP90], and the miner/node strategy changes 2, 3, and 4 of [EIP86]).
   - **Networking** - includes improvements around [devp2p] ([EIP8]) and [Light Ethereum Subprotocol], as well as proposed improvements to network protocol specifications of [whisper] and [swarm].
   - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names ([EIP6]) and [contract ABIs]. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
   - **ERC** - application-level standards and conventions, including contract standards such as token standards ([ERC20]), name registries ([ERC26], [ERC137]), URI schemes ([ERC67]), library/package formats ([EIP82]), and wallet formats ([EIP75], [EIP85]).
@@ -46,11 +46,11 @@ REVERT (0xfe)
 
 ### Shepherding an EIP
 
-Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm).
+Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the *Ethereum Community*.
 
 Before you begin writing a formal EIP, you should vet your idea. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research. It is thus recommended to open a discussion thread on [the Ethereum Magicians forum] to do this, but you can also use [one of the Ethereum Gitter chat rooms], [the Ethereum subreddit] or [the Issues section of this repository]. 
 
-In addition to making sure your idea is original, it will be your role as the author to make your idea clear to reviewers and interested parties, as well as inviting editors, developers and community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage.
+In addition to making sure your idea is original, it will be your role as the author to make your idea clear to reviewers and interested parties, as well as inviting editors, developers and community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage. It is strongly recommended to discuss the proposal with the [*Ethereum Core Developers*](https://github.com/ethereum/pm) before moving the standard past the Draft stage, as Core Developers have much relevant experience and opinions that they can add to a proposal.
 
 ### Core EIPs
 
@@ -60,9 +60,11 @@ The best way to get client implementers to review your EIP is to present it on a
 
 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.
 
-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.
+These calls generally result in a "rough consensus" around what EIPs should be implemented. This "rough consensus" rests on the assumptions that EIPs are technically sound and their implementation is consistent with the best knowledge available of the political will of the Ethereum community.
 
-:warning: The EIPs process and AllCoreDevs call were not designed to address contentious 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. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that [the Ethereum Magicians forum] thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.
+:warning: The EIPs process is not intended to fully capture the political will of the community. As a technical standardization process, the best case scenario for EIPs that may be politically contentious is to standardize the technical details of a proposal as a reference point for political debate to occur. No political decisions occur as a result of the EIP process, as political speech cannot itself be subject to standardization.
+
+:warning: The client implementers will do their best to be as aware of the political climate surrounding a proposal as they can find the time and energy to do so, but their failure to understand all political discussion around contentious issues should not be considered a shortcoming of the process, nor a value judgement of their effectiveness at this role. As the shepherd of an EIP, you can make the process of building community consensus easier by making sure that [the Ethereum Magicians forum](https://ethereum-magicians.org/) thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented. This collective sentiment of the community should be presented, in full, with detailed descriptions of the various facts and opinions the community holds surrounding the proposal, to the client implementors on the AllCoreDevs call, so they have the most relevant information available to make decisions of what to implement in their clients on behalf of their users. The community ultimately uses the software that client developers implement to signal the configuration of the main Ethereum network during critical upgrade periods, and the decisions the client developers make should reflect the simplest configuration possible for what they expect the communities' decisions to be.
 
 *In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.*