Changes EIP-1 wording to focus on technicals not community sentiment. #1224
Conversation
|
I added wording on what happens if a Core EIP is voted down during the Core Dev meeting. This may be a more contentious change than the others so it is in a separate commit and I am willing to remove it and put it in a separate PR if that is preferable. Note: My goal with this PR is not to substantially change the EIP process. It is instead to add clarity to what the real process is. I believe that if the Core Devs vote no on a Core EIP that it is effectively rejected and we should do our best to document that, rather than leaving the EIP in some limbo state that doesn't reflect reality. |
|
Some discussion can be found here on Ethereum Magicians as well as a bit on Gitter |
|
A couple more changes to this: I also changed Last Call for Core EIPs to move directly to Accepted, without waiting on feedback from Core Devs. The EIP process does not define how Core Devs behave, it only defines the EIP process. |
|
This looks reasonable to me. I'd like to hear from other editors and core devs before merging, though. |
| * :arrow_right: Accepted (Core EIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted. | ||
| * :arrow_right: Final (Not core EIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final. | ||
| * **Accepted (Core EIPs only)** -- This EIP is in the hands of the Ethereum client developers. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process. | ||
| * :arrow_right: Final -- Standards Track Core EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”. |
There was a problem hiding this comment.
Can we be more specific on what it means to be "adopted by the community"? does this mean it has been activated in a HF?
There was a problem hiding this comment.
I'm currently more or less in agreement with Nick on the direction to take with the whole "adopted"/"supported" thing. This change was intended only to use a slightly more clear word, without getting bogged down in debate about specifics.
Do you feel that supported was more clear than adopted? If not, do you think that adopted is less accurate of the current process than supported? If not, then I recommend we stick with adopted and debate whether this terminology should be used at all in a future PR.
|
Can we also update the Status term definitions in the README to keep it consistent with the definitions in EIP-1? We could also remove them from the README, but they were originally added as a convenient glossary (it helped prevent confusion when readers would see Status terms in the EIP headers and infer what they meant, without digging through EIP-1 to read their definitions). |
|
Let's also re-add the sentence about the |
|
Sentiment is an important part of last call process. I oppose removing such language. Very soon, a successor to ERC-20 will be proposed. Let us question, what is the threshold for such a supplantation? Imagine if I shall create an EIP that makes a simple, implementable change and then I declare ERC-20 to be superseded. Then EIP-1 (as amended by this PR) will be vulnerable to letting past such a change without studying the sentiment and impact of the replacement of ERC-20. |
|
And again, if sentiment should not be part of the EIP then demonstrate it using actions, not words. You just need to merge #894. |
|
@cdetrio I have updated the Readme. I'm not particularly satisfied with it, but I'm not sure how to make it better in this PR without coming to agreement on actual changes to the process. I do plan to submit a follow-up PR that proposes actual changes to the process, but that is likely to be much more contentious and I want this PR to just be clarification. |
All of the recent changes to the EIP process have been made to ensure that the EIP process is a technical one, and not one of sentiment analysis. There is a lot of discussion going on with regards to how we can improve the process and get valid community sentiment analysis pre-fork, but there doesn't exist a complete solution yet at this time (just proposals). It appears that the Last Call PR introduced sentiment analysis into the process, which I do not believe was intended. From my recollection of the discussions around the Last Call stuff, the goal wasn't to fundamentally change how governance works, but rather to ensure that EIPs don't get stuck indefinitely in limbo. This change simply removes the sentiment analysis wording from the process and makes it more clear that the EIP process is about gauging technical feasibility, not making judgement calls as to whether or not a thing is a good idea or not.
|
@cdetrio I have added the Active state to EIP 1. I left it out of the Readme because I feel like it is largely irreverent in the majority of cases, and it feels like something that doesn't need to be presented front-and-center. |
|
@fulldecent I recognize that sentiment analysis is something people want as part of the EIP process, but it currently isn't part of the EIP process. Also, sentiment analysis is a very hard problem to solve and should not be added frivolously. It especially shouldn't have been added in the Last Call EIP since discussion there was around the Last Call mechanics, not sentiment analysis which is why I believe most reviewers missed it. This PR is meant to rollback the addition of sentiment analysis because its addition was not the intention of the editors (as I have interpreted from conversations with them).
That is fine by me. There likely will be several EIPs that supersede ERC-20. |
Why? What purpose is served by introducing sentiment into a technical standards process?
There's not presently any explicit mechanism for marking a Final EIP as Obsolete. You're welcome to submit a "better than ERC20" standard, but there's no mechanism for you to set it as the "official" successor to ERC20.
894 is not a well-formatted EIP - it purports to change the process defined in EIP 1, but instead of being a PR to EIP 1, it's a separate EIP. That's not the correct process, and as a result it's not a valid EIP. |
|
@cdetrio Have your concerns been sufficiently addressed either with changes or comments? |
|
These changes will result in a flood of technically compile-able and completely f------ useless EIPs. I will not argue for or against that part of the change. But I think we should recognize this impact and do a couple things BEFORE this merges:
Precedent for these changes is the Swift Evolution process. And, of course, I'm not here to waste anybody's time. I offer to implement the above changes if people here with commit access do welcome such a change. Just LMK. |
|
Separate issue: I still think we should remove the REPLACES metadata for EIPS if this is merged. The word REPLACES for an accepted/final EIP seems to imply an endorsement from the EIP editors that the new version is superior and the old version is outdated. The minute we merge this PR, seven people are going to propose replacements to EIP-20. |
|
If nobody states an objection, I will merge this change on Friday. @fulldecent Replaces may still be useful if the original authors of the EIP being replaced to agree with it. There's nothing stopping people from proposing replacements for ERC20 right now, and indeed they already do. |
|
No replacement for ERC-20 has been accepted as final. Your note “replaces may be useful” is not contested. The issue is what happens when the original author does not consent. I oppose merge because the prerequisite preparation for incoming shitstorm has not been handled. I have proposed a solution and it is actionable. Lastly, this PR changes the scope of the EIP process. It is a significant change. The most recent change to EIP1 was #1100 and that was a smaller scope change. The threshold to accept that change was high — it included positive reviews from four EIP editors as well as other positive reviews and zero dissent. If that is the standard then I would say Nick does not have sufficient authority to schedule the merging of this PR.
|
This is an issue right now; this proposal won't change that.
I don't understand why you expect an "incoming shitshorm". Everything you mention people could do right now.
I don't think it's reasonable to take the input from the last change and conclude that's the minimum required to establish consensus. I also don't think it's a good idea to let valid proposals stall indefinitely if they don't get enough input. |
|
I think I should support this, because I will support Ethereum having more hard forks and fragmentation. Consensys has not done a good job maintaining their code or documentation, so more competition will be better for everyone. Let the fork wars truly begin. |
|
@Arachnid #1297 is the missing half of this PR. Remaining work to do on this PR:
@pirapira if all the sentiment is removed from EIPs as per Nick's proposal and the additional changes in this comment then would you consider to return as an editor? |
|
The changes you mention that are "remaining work to do in this PR" are out of scope of this PR. The purpose of this PR is only to emphasize that EIPs do not need community consensus to proceed through the process. There are much bigger changes that I believe are needed in EIP-1 that I would like to work on in another PR after this one but this one intentionally constrained to solve the immediate problem of a recent change introducing a requirement of community consensus. |
|
I'm happy with the state of this, and nobody other than @fulldecent has voiced objections, so I'm going to merge it. Like @MicahZoltu, I think further changes are best addressed through further PRs with their own self-contained justifications and review. |
All of the recent changes to the EIP process have been made to ensure that the EIP process is a technical one, and not one of sentiment analysis. There is a lot of discussion going on with regards to how we can improve the process and get valid community sentiment analysis pre-fork, but there doesn't exist a complete solution yet at this time (just proposals).
It appears that the Last Call PR introduced sentiment analysis into the process, which I do not believe was intended. From my recollection of the discussions around the Last Call stuff, the goal wasn't to fundamentally change how governance works, but rather to ensure that EIPs don't get stuck indefinitely in limbo.
This change simply removes the sentiment analysis wording from the process and makes it more clear that the EIP process is about gauging technical feasibility, not making judgement calls as to whether or not a thing is a good idea or not.