Updates to EIP-1 to reduce the dependence on ACD for Acceptance #2551
Conversation
To more accurate depict the scenarios present in political issues and contentious debate
|
I believe this definition brings into the function parameters a highly undefined and, currently, indefinable collective of individuals. Without an "organization" of the community its definition is too vague and may be easily overtaken by "popular influencers" on main social channels which may or may not have direct involvement into the ecosystem. In absence of any accountable definition of community or members who claim to speak on behalf of it I'd abstain to enter it in a document which acts as a specification guideline. |
|
In my opinion EIP-1 should enforce the path to a technical analysis of the proposals with accountable impacts on the code. Adoption though is not in the scope of EIP-1 (imho) and should be determined on behalf of wider consensus collected from external sources (aside the technical ones). |
|
Should these circumnstance not exist it'd be impossible to have a "draft" EIP implemented in official testnets for example. |
|
I really like these changes. Although, as Andrea has pointed out, some terms are vague, IMO it's nearly impossible to define them very specifically and we should trust people's judgement on this. As we've seen, there is no "clean" way to measure consensus, so I don't think EIP-1 can provide more than a general description of the process. +1 from me 😄 |
|
Mentions of "the community" are left potentially vague to show that creating dialogue with the community (which a very open and fluid by definition) will help in building consensus around the EIP as "well-formed". Basically, you want the most feedback and diverse opinions collected as possible so you can make good decisions on when a proposal is technically complete and should move forward with Last Call. Socialization of the EIP with the community leads to better results within the process. Mentions of "the community" should not be a gating process on the move to Last Call, basically the power lies with the author to make the determination of when a proposal is as technically complete as it's likely to get. Political arguments should also not be a gating process for it moving from Last Call to Accepted, as they cannot inform implementable changes to the proposal in most cases. I'm not sure this is all clear yet, but this is what I was trying to do. |
Yeah, I think part of this is the realization I've had that "consensus" means "no further changes necessary for the proposal to be well-formed" and not as a gating mechanism to prevent the proposal from moving further along in the process. Another (more drastic) thing I want to do is actually explore removing Accepted from Core EIPs. That way, only proposals which are Final could be considered for inclusion by client implementers, and it streamlines the process a lot more. I don't think which proposals are implemented in Ethereum clients is as useful in the EIP process as people think, that should be a separate list. I haven't fully rectified what this would mean though, there is some value to core developers being able to feedback small changes into an EIP as they are implementing them (which are larger changes than errata would allow) Edit: I think I figured out how Final should differ from Accepted. An EIP should only move from Accepted to Final once it has been implemented in several major clients. This would show that the proposal is technically well-specified enough to implement. The gate on Final that an EIP be activated on the Mainnet (or any other public Ethereum network) is unnecessary, and leads to reliance on the political decision-making process of what goes into a network upgrade (sentiment which can change over time, like ProgPoW has) |
|
I believe the core to all the problems everyone is experiencing with polarizing issues like ProgPOW is captured by the following exchange: @fubuloubu said: And @timbeiko said: As we all know, it’s all about consensus. As long as there is no “clean” way to “standardize” and “measure consensus” at scale, there will always be a lack of authority to tell everyone what we should be accepting. This authority vacuum must be filled by something, and to date, hierarchies are the only structure that can scale large enough to fill this authority vacuum. That is why we’ve been doing research and development on achieving “clean ways to standardize and measure consensus”. We simply must find some way so everyone can efficiently communicate, concisely and quantitatively, what everyone wants in a way where everyone gets a voice. If you can build and track what everyone wants, in the fewest possible camps, in real time, at scale - this is what a “standardized” definition of what everyone currently wants should be. Knowing what everyone wants is, by definition, consensus. Once we have a standardized representation of what that is, when hierarchical leaders want to go to war against other hierarchical leaders, we can finally say to them: “Knock yourself out. As for the rest of us, we now know, concisely and quantitatively, what we want, so we’re going to do that instead.” That is legitimate vacuum-filling authority. No single leader can be expected to know the “collective sentiment of the community” and present that to whoever is making decisions regarding acceptance. And using current “social media tools” just polarizes everyone. We’re developing methods and tools to pull people back together, so the community can build and track consensus in the fewest possible camps, with no censoring, so everyone can get a voice. This has been our priority since this is the one piece missing to make leaderless organizations work. We’d be happy to help implement what we have so far, or anything that can be shown to work better anywhere. Having real time “standardized” consensus information would help with (if not completely eliminate) polarizing issues like ProgPOW. |
|
For clarity, the entire point of this set of proposed changes is to remove "consensus" from the EIP process, turning it into more a recommendation than a requirement. As a requirement, it leads to the kind of issues you mentioned, which cannot be fixed without adapting a different political structure. EIPs are apolitical. |
|
@fubuloubu said:
Good point. EIP 1 currently says: "The EIP author is responsible for building consensus within the community and documenting dissenting opinions." I think it is OK to say this needs to be done? and that it should be done, some place else? |
|
@gcolvin just pointed out the authority vacuum in the ProgPow Review gitter channel: “#EIP-1 doesn’t appear to define "Eligibility for Inclusion”. I don’t recall what the requirements are for that status.” |
This is important to make further distinction with. "Building Consensus" means having broad feedback about the proposal available through socializing the proposal, in order to have the best technical implementation possible. This is done so that standardization is successful and the standard is likely to see use. If the author does a poor job at this, it is likely that the standard won't be adopted due to being technically ill-formed, regardless of it's politics. |
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Motivation
During the Great ProgPoW Debates of 2019-2020, it became clear to me and several others familiar with the EIP process that unnecessary emphasis is placed on the approval of the Core Developers (from within the ACD call) for EIPs to move forward in the process. Their "approval" is a decision that exists outside of the EIP process, and those who might have an interest in the status of an EIP could become confused at the meaning of different stages of the process and their level of "official-ness"
This rewording on EIP-1 is meant to make it clear that the EIP process is solely a technical standardization process, and while it does mention the considerations of client developers (who ultimately must implement given standards into their clients), it de-emphasizes their role in "approving" proposals so that space can be given to other stakeholders to add their input to the process.
TODO
I am beginning this PR as a Draft, seeking comment on how I can best enact this motivation, in order to reduce the misunderstanding that the EIP process is responsible for the configuration of Mainnet Ethereum, and that the Core Devs have sole power and responsibility to reject Proposals or declare them "Approved".
Currently, I have only updated informational passages of EIP-1, the procedures are purposely left untouched so as not to disturb the overall process as it stands.