Title: Reviewing_the_current_EIP_process
Category: Magicians

Author: jpitts
Date: 2018-02-20T06:50:52.149Z

Let’s get to know the current EIP process (as documented in EIP-1):
EIP-1: Purpose and guidelines for Ethereum Improvement Proposals
EIP Rational
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum.
Three types of EIP

Standard Track EIP


Core
Networking
Interface
ERC - application-level standards and conventions



Informational EIP - design issue, or provides general guidelines or information to the Ethereum community


Meta EIP - procedures, guidelines, changes to the decision-making process, and changes to the tools


EIP Work Flow
The EIP process begins with a new idea for Ethereum.

Each EIP must have a champion
A draft EIP should be presented as a pull request

Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification.

It must be a clear and complete description of the proposed enhancement.
The enhancement must represent a net improvement.
The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

Once an EIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”.
What belongs in a successful EIP?

Preamble
Simple Summary
Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Test Cases
Implementations
Copyright Waiver

EIP Editor Responsibilities and Workflow
For each new EIP that comes in

Read the EIP to check if it is ready: sound and complete.
Edit the EIP for language

Once ready for the repository:

Assign an EIP number
Accept the corresponding pull request
List the EIP in README.md

The editors don’t pass judgment on EIPs. We merely do the administrative & editorial part.

Author: AlexeyAkhunov
Date: 2018-02-21T19:36:04.513Z

Nick Johnson has been tweeting about IETF process, maybe something can be taken from there: https://www.rfc-editor.org/rfc/rfc7282.txt

Author: jpitts
Date: 2018-02-21T20:59:39.125Z

I think a lot can be learned from the IETF in terms of process, particularly from the notion of “rough consensus”. On Consensus and Humming in the IETF by Pete Resnick (which you have referenced) shows how seriously they take effective decision-making.
Also, this is Nick’s tweet thread on reaching consensus: https://twitter.com/nicksdjohnson/status/966381359051796485.
Greg has been championing the idea of learning from the IETF and other standards bodies for a long time now, and we should. Definitely point to any other organizations (even corporate as in Zappos) that we can learn from.

Author: jpitts
Date: 2018-02-25T02:20:10.058Z

Nick Johnson @Arachnid recently posted a comment on EIP-898 that describes current operating process really well. His description illustrates how the de-facto process is different from the process outlined in EIP-1).

Here’s my understanding of the current process, based on EIP 1 and experience:

Someone submits a draft EIP as a pull request
Interested participants debate the proposal until consensus on the contents of the draft have been reached.
An EIP editor merges the PR as a draft
Someone submits a PR to update the draft; repeat from step 2.
Once the EIP is ‘mature’, if it modifies the protocol it’s discussed at an All Core Devs meeting. If the participants agree it’s a good idea, they implement it in their specific clients, and the EIP moves to ‘accepted’.
Once implemented, if the EIP modifies consensus, it’s added to a scheduled hard fork.
The hard fork and its contents are announced, and users have the opportunity to determine if they accept the hard fork or reject it.
The hard fork block is reached, and people upgrade, or don’t.

Author: tjayrush
Date: 2018-03-02T16:47:02.098Z

I’ll start. Each item in the above list (with the exception of item 2) has a pretty clear group of participants: (1) someone…, (3) an EIP editor, (4) someone…, (5) core devs, (6) core devs (implicit), (7) miners, (8) miners. Item (2) has ‘interested participants’ which is ill-defined.
The primary concern, if I may try to voice it, is that the portion of the ‘interested participants’ that are not ‘core devs’ and who disagree with the decisions made by the ‘core devs’ (or even disagree that ‘consensus’ has been reached) have a lesser say in what happens.
I’m not suggesting any solutions, only pointing to the crux of issue. The other steps seem pretty clear to me.

Author: CryptoHokie
Date: 2018-03-02T18:33:14.621Z

I think the problem lies in #2 first and foremost. Debating until consensus is reached. It’s not a great model for a few reasons, 1) no explicit time constraints on debate, and 2) no explicit definition of consensus.
Also #5 “if the participants agree…” this implies that after consensus has been reached and the EIP matured, the Core devs still have a layer of approval for go/no go. This marginalizes the participants in the initial consensus process described in #2 if that process includes parties outside the Core devs. There needs to be clarification that this agreement/veto only occurs based on technical grounds (e.g. we merged it, we tested it, it doesn’t work we can’t do it). That is the only condition in my mind where the Core devs should retain an ultimate go/no go vote after the initial public debate / social consensus regarding the EIP was reached.
In matters of pure technical viability, Core devs should retain that final say post testing.
I’d imagine a conditional workflow for the EIP consensus and I can draw something up. I think we want this to be as lean and efficient a process as possible but also, as inclusive as possible.

Author: Arachnid
Date: 2018-03-02T19:04:18.690Z

tjayrush:

I’ll start. Each item in the above list (with the exception of item 2) has a pretty clear group of participants: (1) someone…, (3) an EIP editor, (4) someone…, (5) core devs, (6) core devs (implicit), (7) miners, (8) miners. Item (2) has ‘interested participants’ which is ill-defined.


7 and 8 are not ‘miners’, they are ‘economic participants’. Miners don’t decide which hard fork gets adopted, they follow the money. They can mine whatever fork they want, but since reorgs don’t happen across hard forks, that has no impact on which side gets accepted by the community.



 CryptoHokie:

Also #5 “if the participants agree…” this implies that after consensus has been reached and the EIP matured, the Core devs still have a layer of approval for go/no go.


Ultimately, this will always be the case: you cannot force the implementers of a piece of software to write or merge changes they do not agree with. If you want to force a change against the wishes of the maintainers, you will have to fork the code and do it yourself.

Author: CryptoHokie
Date: 2018-03-02T19:08:57.813Z

Arachnid:

Ultimately, this will always be the case: you cannot force the implementers of a piece of software to write or merge changes they do not agree with. If you want to force a change against the wishes of the maintainers, you will have to fork the code and do it yourself.


Yes, but that is meant to be debated in #2, not number five. If the general consensus is to move forward with an EIP after the open debate (which the devs are a part of), then by vetoing or refusing to merge the developers have exacted their own will upon the state of the blockchain, which needs to be effectively reduced to near zero. Not only to protect the governance process and keep it fair, but also to protect the EIP editor should issues of legality from action / inaction arise (as Yoichi pondered).

Author: CryptoHokie
Date: 2018-03-02T19:13:43.640Z

Actually I’m wondering if the open debate / initial social consensus guage should be occurring before an EIP is even submitted. Or some sort of agreement on what classes of changes are even allowable for EIP submission (thin line here since that requires a definition for classes of changes which itself would require consensus). Thinking behind that, though, is if anything can be submitted as an EIP, the community and devs can be inundated with consensus votes, so much to the point where participation will be affected due to the sheer volume of proposals on the table at any given time.

Author: Arachnid
Date: 2018-03-02T19:49:42.058Z

CryptoHokie:

Yes, but that is meant to be debated in #2, not number five.


Disagree. Engineers who work on clients can comment during #2, but just because there’s technical consensus on the contents of an EIP doesn’t mean that they are happy to implement it in their clients. There’s a number of reasons they might object to implementing the EIP even if the specification is stable.
In my mind, the role of EIP editors should be as straightforward as possible, which means assessing as objectively as possible whether a standard is stable; this doesn’t imply assessing an EIP’s viability.



 CryptoHokie:

Actually I’m wondering if the open debate / initial social consensus guage should be occurring before an EIP is even submitted.


It’s very difficult to debate the merits of something that isn’t sufficiently specified.



 CryptoHokie:

Or some sort of agreement on what classes of changes are even allowable for EIP submission (thin line here since that requires a definition for classes of changes which itself would require consensus).


Again, trying to build in restrictions on what can be standardised misses the point. There’s nothing that says that hard fork changes have to come from EIPs; if we make the EIP process harder to navigate, people will just go elsewhere. EIPs are an input to the hard fork process, not part of the process itself.

Author: CryptoHokie
Date: 2018-03-02T20:01:38.105Z

So why not do away with any sort of social debate if the developers are ultimately the gate keepers anyway?
I also don’t get what you’re saying up top about there being technical consensus but clients not wanting to implement. If it reaches the defined consensus point for acceptance, and they disagree with it, they’re free to fork. We can’t let EIPs just die because one client or one subset of interest groups disagrees, that defeats the entire point of consensus, no?
At the end of the day the devs need to either honor the consensus or we abandon the thought of a greater community inclusive consensus, because devs will ultimately be acting as gatekeepers anyway, which in my opinion, defeats the purpose of trying to make any sort of decentralized governance process work.

Author: CryptoHokie
Date: 2018-03-02T20:02:54.663Z

And that’s ok. But it needs to be made clear up front. EIP-1 does not make that clear enough in my opinion.

Author: Arachnid
Date: 2018-03-02T21:22:17.008Z

CryptoHokie:

So why not do away with any sort of social debate if the developers are ultimately the gate keepers anyway?


Because devs won’t implement something if they’re sure nobody wants it - and they’ll be more inclined to implement something if there’s clear signs it’ll be useful to people. Feedback is good.



 CryptoHokie:

I also don’t get what you’re saying up top about there being technical consensus but clients not wanting to implement. If it reaches the defined consensus point for acceptance, and they disagree with it, they’re free to fork. We can’t let EIPs just die because one client or one subset of interest groups disagrees, that defeats the entire point of consensus, no?


Suppose there’s consensus on an EIP that would slow down a client implementation by a factor of 10 if implemented. Clearly, client implementers would reject this.



 CryptoHokie:

At the end of the day the devs need to either honor the consensus or we abandon the thought of a greater community inclusive consensus, because devs will ultimately be acting as gatekeepers anyway, which in my opinion, defeats the purpose of trying to make any sort of decentralized governance process work.


I think you’re being ambiguous about what you mean by ‘consensus’.
In the EIP writing process, it’s agreement on what the standard should contain.
When it comes to the chain, ‘consensus’ is what clients preserve.
When it comes to adopting or not adopting changes, ‘consensus’ is something the community agrees on.
Ultimately, there’s no way to force client implementers to implement something that they don’t think is a good idea. No amount of legislating can get around that.

Author: CryptoHokie
Date: 2018-03-02T21:34:28.883Z

I think I see what you’re saying, regarding the clients not updating/implementing, effectively refusing the change. I guess I was talking about before it even comes to that. The “social consensus” between the community and the devs (versus technical or on chain). Getting from the open debate about a change to the standardization in an EIP and ultimately merging and implementing. Right now I feel like there’s a lack of clarity on what should or shouldn’t be submitted as an EIP, and where the  decision making process lies in that regard.
I can abandon using the confusing terminology and just refer to it as the initial public debate and path forward versus “social consensus”

Author: MicahZoltu
Date: 2018-03-02T23:42:34.427Z

Really the way the governance process works is a series of vetos.  None of the vetos stop the process from moving forward, but a group exercising their veto power makes it significantly harder for the process to move forward for others.

First veto is the EIP editors, who can choose to not merge an EIP into draft.
Second veto is the Core Devs group, who can choose to recommend against a change.
Third veto is the client dev teams, who can choose not to implement a change.
Fourth veto are economic participants, who can choose not to use a client that implements a change.

The process can be skipped/bypassed by anyone.  As a user, I can fork a client, author a change, and then run a node containing that change  I will have successfully hard forked with the change I desire, but it is unlikely that anyone would join me on my chain in this case.  Thus, the veto powers at each step are weak at best.
The system has inertia as well.  If something makes it all the way to implemented in clients, it has a lot of inertia and it is actually reasonably difficult to get the community to not move forward with that change.  Similarly, if the Core Devs call results in agreement on a change, it would be hard for a single client to exercise their veto power (but they can certainly try).

I’m personally a fan of this mechanism for client development and protocol improvements.  I think democracy and voting in general is a terrible process because the vast majority of voters are largely uninformed and vote with their heart, not their head (I have personally done this in the past as well, it is human nature).  This process allows people who have spent a lot of time thinking about an issue the least amount of inertia pushing against them and those who have spent less time more inertia to fight against.

Author: Arachnid
Date: 2018-03-03T07:50:19.803Z

This is an excellent description of the process. I agree.
Does anyone else think we need an “I’m only an EIP” infographic/comic/animation to explain the whole process?

Author: jamesray1
Date: 2018-03-04T05:09:50.370Z

jpitts:

Once an EIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”.


I disagree, client developers can choose. So I suggest that you say, “Once an EIP has been accepted, client developers choose whether to adopt them or not. If the EIP is adopted in implementations, then the community has to choose whether or not to upgrade their clients. Once the majority have updated their clients then the EIP can be considered to be adopted by the community, and the status can be changed to final.” However, an issue with this last point is that you would need to somehow track the percentage of upgrades to the latest implementation.

Author: jamesray1
Date: 2018-03-04T05:12:25.994Z

jpitts:

What belongs in a successful EIP?
Preamble
Simple Summary
Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Test Cases
Implementations
Copyright Waiver


Note that not all of these are always applicable, e.g. Backwards Compatibility, Test Cases, and Implementations. I have wrote a few EIPs and I have just left the template for these sections or commented them out.

Author: jamesray1
Date: 2018-03-04T07:41:57.628Z

https://www.rfc-editor.org/rfc/rfc7282.txt is worth reading. It raises an interesting governance process that could be applied beyond technical systems: eliminating objections or discarding a proposal if the objection can’t be technically fixed. However you would still need some kind of signalling/voting to replace humming (which starts the process of consensus), because humming can’t be done at scale and needs most stakeholders/participants to be involved in person, but like rough consensus, this signalling would be the beginning of the process. When I first heard about rough consensus I was skeptical, but this article gives a reasonable exposition of why it is useful, and better than just voting.

Author: fulldecent
Date: 2018-03-10T03:49:17.049Z

Hello, I’m Will Entriken. I wrote/championed the latest two EIP drafts that got merged, and have been involved a little in the Solidity project.
How can I help here? And what will a win look like for the Magicians project?
FYI, I am here representing myself, not part of any organization and I haven’t found any funding yet.

Author: fulldecent
Date: 2018-03-12T16:01:51.644Z

I will be attending and presenting at Exploring 721 in Dallas next weekend (discussing ERC-721). One of the topics is reviewing the standards process.
Maybe I am not the most qualified to speak on this panel, but I will do my best to inspire the next round of EIP contributors.
I hope this thread can be active in the next week so that I may learn more and be useful at the event. Of course you are all welcome to attend.

Author: jpitts
Date: 2018-03-12T18:24:06.619Z

Thanks @fulldecent, this is a great opportunity to educate people in the community about the process and then to get them involved.

Author: fulldecent
Date: 2018-03-12T20:37:20.311Z

Here’s all my open questions, and others I’ve heard about the current EIP-1:

Who assigns the editors?
Are the term limits or any other qualifications or restrictions on editor participation?
How does the champion summon an editor to initiate review?
What is the “Ethereum philosophy”?
How do you get from draft to final?
How do you “win” as an EIP author?

Here is every problem I see with the current process:

There is a strong incentive for anybody who has an interface in their program to go and standardize that interface. This results in a heaping pile of ERCs for use cases that are imagined at best. Personally I have a much higher threshold for use cases and consensus.
Because of the noise, it is difficult for interested and useful people to find EIPs that have a reasonable chance of passing.
The needs of the deciding stakeholders (“the community”? Ethereum Foundation? people with commit access to ethereum/EIPs?) are not well documented. Personally for any open source project I work with, it is nice to know you are working on a welcome problem before sending a pull request.

The identity of the stakeholder is unclear. If [ the Ethereum Foundation will decide on EIPs during the Project Management/All Core Devs meetings and if that meeting sets the direction of go-ethereum/Parity and if those projects are critical for Ethereum ] then effectively only the people that can vote there matter. It should be more clear whether this is the case.
The process to amend EIP-1 is not defined.

Author: gcolvin
Date: 2018-03-27T17:13:33.424Z

One issue is that the notion of a “mature” draft is ill-defined.  There should probably be a status called Ready which means that the Editors have approved it so far as meeting editorial standards, and the author believes it is ready for consideration by the core developers.

Authors will likely not move a proposal forward absent consensus by the Fellowship, but (again) the Fellowship has no power here, it is the author’s proposal and the author’s choice.
Alternatively, the Editors can choose not to move a proposal to Ready status absent Fellowship consensus.  Though again, anyone is free to submit proposals to the core devs independently.

Author: Arachnid
Date: 2018-03-28T11:42:20.260Z

I’ve written up an EIP draft proposing a revision to the EIP process here. Feedback appreciated.

Author: jpitts
Date: 2018-05-02T03:44:50.520Z

Useful “flow chart for how changes are currently made to the Ethereum platform”, tweeted by Dan Finlay:


twitter.com



Dan Finlay (danfinlay)
 Here's a flow chart for how changes are currently made to the Ethereum platform. #EIP0

8:33 PM - 1 May 2018



 281
    



 92

Author: tjayrush
Date: 2018-07-18T15:26:53.174Z

Has there been any suggestion about an EIP status called ‘Withdrawn’?
There’s been discussion about ‘closing’ EIPs if they never enter Final Call or if the do enter Final Call but get rejected, but there doesn’t seem to be a way to remove an EIP from active consideration.
The reason this matters to me is, if one thinks about new entrants to the space, whose best way to learn about what’s going on in a deeply technical way is to read every comment on every EIP, it would be helpful if they could easily identify EIPs that have little or no chance of ever becoming part of the spec (to the extent that there is a spec).
If there was a status called ‘Withdrawn’ the author could, much like moving an EIP to ‘Final Call’ simply move the EIP to ‘Withdrawn.’  The Core Devs then have a bit of an easier path. If they simply ignore the EIP, or speak about it briefly and don’t suggest that the author moves it forward, then hopefully, the author will get the idea that it’s best to move the EIP to withdrawn.
The header of withdrawn EIPs could be colored pink or something to make them obvious.
Thoughts?

Author: lrettig
Date: 2019-03-18T20:49:50.048Z

We should bring this up again. It came up on a recent core devs call when @chfast offered to withdraw EIP-1355 (see https://github.com/ethereum/EIPs/pull/1785/files) but we realized that there is no “withdrawn” status.