EIP Community Veto #904
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| ## Preamble | ||
|
|
||
| EIP: <to be assigned> | ||
| Title: EIP Community Veto | ||
| Author: Sam Griffin (sam.griffin@gmail.com) | ||
| Type: Meta | ||
| Status: Draft | ||
| Created: 2018-02-24 | ||
| Modifies: EIP-1 | ||
|
|
||
| ## Simple Summary | ||
| The greater Ethereum community should be able to veto EIPs they don't like. Also, the process by which EIPs become part of the Ethereum standard should be clarified. | ||
|
|
||
| ## Abstract | ||
| Some EIPs have contentious moral/ethical/legal/philosophical rammifications. The process of drafting the EIP where the author comes up with what they think is the best form of their idea should be free from interference, but the community should have a voice to prevent unpopular EIPs becoming part of the standard. | ||
|
|
||
| ## Motivation | ||
| The community currently has no official procedure for indicating their dislike of certain EIPs. This leads to brigading of GitHub pull requests that make it more difficult for EIP editors and draft writers. Additionally, EIP draft writers do not have specific data on how controversial their EIP is. Controversial hard forks should be avoided whenever possible, and if compromise can happen in the EIP drafting stage, this could avoid community splits. The current role of the AllCoreDevs group is also not detailed in EIP-1, and this should be made explicit. | ||
|
There was a problem hiding this comment.
This isn't true. They indicate their dislike by not upgrading their nodes to run protocol changes. The community's role in the governance process (currently) is that of final veto power. While I appreciate that many people don't like this mechanism and prefer majority (mob) rule, it is incorrect to state that the community has no official procedure. There was a problem hiding this comment.
You should specify in the EIP why you believe that controversial hard forks should be avoided. I personally think that controversial hard forks are the single advantage that this type of governance has over traditional democratic governance. There was a problem hiding this comment.
Agreed, and EIP-1 should be updated to reflect that. However, creating an EIP that suggests that someone update another EIP for clarity isn't the proper procedure, instead I recommend just submitting a PR for EIP that adds the clarity. There was a problem hiding this comment. A problem with hard forks is that for every fork, people would have to dedicate time and effort to build clients on the new fork and implement changes (e.g. ones that they agree on from EIPs). Voting can provide signalling for decision making on whether to proceed with a change on Ethereum if there is a majority vote (which could also include criteria for key stakeholders like clients, miners/validators, core devs, etc.), otherwise, if not, people can choose to fork Ethereum and maintain the fork as they see fit. There was a problem hiding this comment. Yes, the people dedicating resources to authoring a fork are making a bet on where they believe people will trade. However, I'm not convinced that a vote would actually be a valid signal as to the correctness of their actions. As an example, I would have voted against TheDAO, but ultimately when push came to shove I stayed with ETH instead of ETC. If we assume (just for the sake of this discussion) that everyone was in the same boat then the vote would have changed the behavior of the client developers in a way that may not actually have been in the best long-term interest of Ethereum. At the time of The DAO, I wasn't as well informed as I am now and if the vote were to happen today I may vote differently (I'm not actually sure which way I would vote). The problem is that the vast majority of people (like me) who would be participating in this vote are not as well informed as the people coding the clients. It is just the nature of how the world works, often many people who are affected by a particular issue have not devoted a massive amount of time into researching and understanding that issue enough to make the most wise decision. There was a problem hiding this comment. I think it's great that cryptocurrency has the option for communities to peaceably split via hard forks, but I also think it should be the absolute last resort. If a compromise can be found before it reaches the point of a community split, why not? @MicahZoltu surely you don't think that community splits should be common occurrences, do you? There was a problem hiding this comment. Forks lead to more fragmentation which reduces the viability of the community, Standardization through consensus is the norm in most mature SDO's, it would be advisable to maintain at least a set of common standards. A commenting period, where any opposition can suggest how a proposal could be made acceptable, may also improve the incorporation of community comments into an EIP before it starts a decision even needs to be taken. |
||
|
|
||
| ## Specification | ||
| I propose two new phases to the EIP process: "Staging" and "Implementing" | ||
| Once an EIP champion has polished their draft to their satisfaction, it will go to the "Staging" phase. At this point a carbon vote shall be set up and the draft shall be sent to the AllCoreDevs group. The community shall be given a period of a week to register their carbon votes. If the majority of the carbon vote is against the EIP in its current form, it shall be sent back to the "Draft" phase. | ||
|
There was a problem hiding this comment.
This is exactly what merging an EIP as a DRAFT is, what are the advantages to renaming it to STAGING? What is unclear about the DRAFT name? There was a problem hiding this comment. My idea is that at the Draft phase, it is undergoing revision, whereas the "Staging" phase would be for evaluating EIPs that are in a stable state. It's hard to evaluate things as they're being changed. There was a problem hiding this comment. Are you referring to making us of the "Draft" phase to allow for free flow comments to be integrated by the author as they see fit, and a "staging" phase that would be pegged against a delivery date to avoid the instability? There was a problem hiding this comment. The staging phase would have a community vote window, if that's what you mean by delivery date. Client software probably shouldn't be implementing any EIPs until AllCoreDevs and the community carbon votes have passed. It's helpful to have the EIP frozen when the community is voting on it, though, so that it's clear that everyone is voting an exactly the same thing. There was a problem hiding this comment. I meant "promotion" of the standard, not "delivery" |
||
| If the majority of the carbon vote is for the EIP and the AllCoreDevs group is satisfied with the current form, the EIP shall enter the "Implementing" phase. If any implementation details necessitate changes to the EIP, it shall be sent back to the "Draft" phase. If 3 "viable" (what is viable?) Ethereum clients successfully implement the EIP, it shall move to the "Final" phase and be codified in the Ethereum standard. | ||
|
|
||
| ## Rationale | ||
| The contention around EIP-867 made it clear that there was no good way for the community to make its voice heard, and it was unclear if dissent was the result of a few passionate, loud voices, brigading from other cryptocurrencies, or a major community backlash. | ||
|
There was a problem hiding this comment.
EIP-867 has not yet adopted yet, so we can't say that the process failed in some way. People are worried that the process will fail, but we don't actually have evidence of failure yet. While it is unclear if the yelling in that GitHub issue is meaningful or not, the problem is that is not how the community "participates" in the governance process. They participate by choosing a fork to participate in in the future. There was a problem hiding this comment. Whether you support forking or not, would be not be a better process whereby a counter proposal can be reviewed for harmonization prior to fragmenting into a new fork? |
||
|
|
||
| ## Copyright | ||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rammifications => ramifications