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.
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.
It’s very difficult to debate the merits of something that isn’t sufficiently specified.
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.
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.
And that’s ok. But it needs to be made clear up front. EIP-1 does not make that clear enough in my opinion.
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.
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.
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.
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”
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.
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?
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.
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.
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.
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.
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.
Thanks @fulldecent, this is a great opportunity to educate people in the community about the process and then to get them involved.
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
interfacein 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.
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.
I’ve written up an EIP draft proposing a revision to the EIP process here. Feedback appreciated.
Useful “flow chart for how changes are currently made to the Ethereum platform”, tweeted by Dan Finlay:
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.