Proposing a revised process for handling of EIP drafts #956
Conversation
|
Meta question: Are you creating an EIP that describes the changes to EIP-1 for transparency-of-process reasons? Otherwise, it might be easier to replace EIP-1 with an entirely new proposal. |
|
I do not support this. Removing: "not in keeping with the Ethereum philosophy", will remove one of the reasons to not merge bailout proposals. |
|
FYI, the build is failing because this EIP uses its own suggested naming scheme, which uses a string for the EIP field. Other EIP fields are integers, and jekyll doesn't know how to sort things of mixed type. |
Yes. If merged as final, EIP-1 should be edited accordingly.
As discussed previously, the "Ethereum philosophy" bit was copied from BIP-1, which copied it from PEP-1. The meaning of "Python philosophy" is quite different from "Bitcoin philosophy" or "Ethereum philosophy", and has no relation to onchain governance. What the "Ethereum philosophy" is has never been succinctly described in a way everyone agrees to. Also as previously discussed, EIPs don't govern the chain themselves, they specify proposed changes. If you object to a change on philosophical or political grounds, the correct mechanism is to advocate against its implementation, not to try and prevent it from being merged as a draft. The EIP editors should not have the power to independently decide whether something is suitable for implementation or not. |
|
Where it comes from is not relevant. It's in there and I want to keep it. |
|
As suggested by @Souptacular, I've changed this PR to edit EIP-1 directly instead of writing a new draft. @sandakersmann I don't find that to be a particularly persuasive argument for keeping it, personally. |
|
This makes a lot more sense to me. Drafts are just that, a way to display a proposal. It should have nothing to do with acceptance or adherence to any Ethereum philosophy. Maybe there can be a temporary compromise by moving that part to the Accepted requirements. |
|
@sandakersmann I do not find the argument to be convincing as well. EIPs that are written to the technical and grammatical standards required should be merged as Draft regardless of controversy. The role of EIPs is for technical discussion and editors should not be gate keepers of ideas based on a nebulous "Ethereum philosophy". That is a dangerous move imo. |
EIPS/eip-1.md
Outdated
|
|
||
| An EIP can also be assigned status “Deferred”. The EIP author or editor can assign the EIP this status when no progress is being made on the EIP. Once an EIP is deferred, the EIP editor can re-assign it to draft status. | ||
| Non-standards track EIPs may be transitioned to 'Accepted' or 'Final' status when the author requests it, and at the discretion of the editors. |
There was a problem hiding this comment.
Why not just pick one: accepted or final? Seems confusing to have both as options for informational or meta EIPs.
|
I prefer to keep the standard we have today in EIP-1. It seems like it is important for keeping people away from merging toxic bailout proposals. |
|
@sandakersmann You are just repeating your argument and not addressing my counter argument. |
|
@Souptacular To say that it is a dangerous move is disingenuous since it has been in there since the start. |
|
@Arachnid discussed why it has been in there since the start in this comment - #956 (comment) Basically it was a copy/paste of the BIPs process so we just changed the words Bitcoin to Ethereum with minimal edits otherwise. I can be completely genuine in saying that it is dangerous to keep that line in EIP 1 because it gives editors too much authority to reject draft EIPs. |
|
I would suggest that a system in which a small group of gatekeepers have the power to refuse standardisation of an otherwise valid proposal based on unwritten rules is "not in keeping with the Ethereum philosophy", personally. |
|
I can see your point of view, but when it seems to be critical to avoid merging of bailout proposals I do not want to remove it. I might change my mind if we include some text banning merging of bailout proposals. |
|
@sandakersmann Thank you for understanding and your concern and perspective are noted. |
EIPS/eip-1.md
Outdated
|
|
||
| Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification]. The EIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the EIP. Standards Track EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final. | ||
| An automated process will check all pull requests; if the request passes the format checks and contains only additions or edits to drafts owned by the submitter, it will be automatically merged. No editorial control is exercised over the content of an EIP draft. |
There was a problem hiding this comment.
I believe "automatically merged" in this context means that an editor will manually merge the document without any other factor manually preventing the merging from happening. As in an editor's personally opinion about the EIP will not make a difference in whether or not it gets merged; if it is technically correct it gets merged automatically by an editor without un-needed delay.
There was a problem hiding this comment.
Already possible on GitHub and happened before. One way to avoid this getting into the repository would be to build a time-delay into the automated process for merging drafts. In case there is a spam-attack or other obvious abuse, there will be some time to correct it.
There was a problem hiding this comment.
There is the "automated process" mentioned. I'd rather label PRs with a bot than merging them.
There was a problem hiding this comment.
I believe "automatically merged" in this context means that an editor will manually merge the document without any other factor manually preventing the merging from happening.
Actually, I was suggesting an entirely automated process. If someone wants to fill the repository with useless drafts, there's relatively little harm in doing so, and we can back it out (delete files) if need be afterwards. Any harm from a spam attack is minimal and easily undone.
There was a problem hiding this comment.
I'm having flashbacks to the last spam attack we faced across Ethereum repos back at the end of 2016 I believe. lol
There was a problem hiding this comment.
We had issues on this repo because each spam tx took up an EIP number - fortunately that wouldn't be an issue here any longer. And it's trivial to revert a repo back to a commit before the spam was added.
|
@nicksavers Good question. I would vote no, since that would break any links people have to the existing drafts. |
|
I would like to have this added to EIP-1:
|
|
@sandakersmann The standardisation process is not the place for you to try and enforce your personal political philosophy on all of Ethereum. |
|
@Arachnid Fine. Then I reject you doing changes to the standardisation process since it is not the place for you to try and enforce your personal political philosophy on all of Ethereum. |
|
@sandakersmann None of the changes proposed in my PR are 'philosophical' in nature; they're all explicitly content-independent. |
|
All changes are 'philosophical' in nature. |
EIPS/eip-1.md
Outdated
| @@ -44,17 +44,21 @@ Each EIP must have a champion - someone who writes the EIP using the style and f | |||
|
|
|||
| Vetting an idea publicly before going as far as writing an EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP. | |||
|
|
|||
There was a problem hiding this comment.
The Fellowship is intended as a (better?) place for working with the community on EIPs. Might be worth calling out here.
EIPS/eip-1.md
Outdated
|
|
||
| For an EIP to be accepted it must meet certain minimum criteria. 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. | ||
| Standards track EIPs of type 'Core' are updated from 'Draft' to 'Accepted' status when a core devs meeting has accepted the draft and the participants have announced their intention to implement the EIP for inclusion in a future hard fork. At that point, an EIP number is assigned by the editors and the EIP is moved to the EIPS directory and renamed accordingly. Once a Core EIP has been implemented in at least three clients, and all pass a common set of test suites, the status of the EIP is updated to 'Final'. An EIP can also be assigned status “Deferred”. The EIP author or editor can assign the EIP this status when no progress is being made on the EIP. |
There was a problem hiding this comment.
This seem very late in the process to assign a number. RFCs get a number much earlier. (BIPs and PIPs too, I think). Without a number it's hard to unambiguously refer to a Draft under discussion.
There was a problem hiding this comment.
I'm actually modelling this after the RFC process; RFCs only get a number after the working group is done with them. The draft can be unambiguously referred to by its name (eip-draft-gcolvin-foo).
There was a problem hiding this comment.
We don't have working groups as an explicit part of our process, and the IETF doesn't have coredevs. The closest we might have to working groups would be groups in the Fellowship, and their work is done when an EIP becomes a Draft. I think this is about the stage at which an RFC gets a number, not the stage at which the whole internet is sure to go with it.
There was a problem hiding this comment.
The other stage where a number might be assigned is my proposed Ready status. The editors, the authors, and any ad hoc working groups (possibly including Fellowship groups) are quite done with it, and as far as we are concerned it's a thing.
There was a problem hiding this comment.
I don't think that's a reasonable analogy. In the IETF, an RFC gets a number when editing is basically finished - by the time it gets a number, it's definitely going to be an accepted RFC. When a draft is submitted, it's barely begun. I don't think it makes sense, or is necessary, to assign EIP numbers to every draft.
There was a problem hiding this comment.
I guess I don't see the point of calling something a Request for Comments when in fact the document is done and not open to further comments. But I don't know their process that well. Anyway, this is again why I propose a Ready status as the right place for us to say our work is done, so here is a proposal, EIP-###. The path from there to being accepted can be long and contentious, and it really will help to have a document number during that process.
There was a problem hiding this comment.
You'd have to ask the original IETFers about that.
I still don't see the need for a separate 'Ready' state; if you want your Core EIP moved to 'Accepted', ask for it to be added to the all-core-devs agenda, and if you want your non-core EIP moved, ask an editor. Neither one requires a state just for that.
There was a problem hiding this comment.
That is, without numbering EIPs until after they are accepted the discussion of EIPs can go like...
"The core devs accepted Nick's proposal."
"Which one?"
"Something like nicks_minimal_troll_vaporization_mechanism".
"You mean the one he presented at NevCon7?"
"No, the one after that, that vaporized fewer cases."
"What's its EIP number?"
"I don't know. It hasn't been assigned yet."
There was a problem hiding this comment.
Is it that difficult to talk about "draft-nickjohnson-lets-vaporize-trolls"? It seems to work well enough for the IETF.
There was a problem hiding this comment.
I understand this conversation happened over 1 year ago.
In my experience in other context, having an ID as early as possible actually helps a lot for disambiguation. What's the benefit of not assigning number, other than feeling not all draft needs number? Is it to conserve number space? @Arachnid
EIPS/eip-1.md
Outdated
| @@ -42,19 +42,23 @@ The EIP process begins with a new idea for Ethereum. It is highly recommended th | |||
|
|
|||
| Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. | |||
|
|
|||
| Vetting an idea publicly before going as far as writing an EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP. | |||
| Vetting an idea publicly before going as far as writing an EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Fellowship of Ethereum Magicians], [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP. | |||
There was a problem hiding this comment.
(If this comment shows up twice, blame GitHub.) The Fellowship is intended as a (better?) place for working with the community on EIPs. Might be worth calling out here.
EIPS/eip-1.md
Outdated
|
|
||
| For an EIP to be accepted it must meet certain minimum criteria. 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. | ||
| Standards track EIPs of type 'Core' are updated from 'Draft' to 'Accepted' status when a core devs meeting has accepted the draft and the participants have announced their intention to implement the EIP for inclusion in a future hard fork. At that point, an EIP number is assigned by the editors and the EIP is moved to the EIPS directory and renamed accordingly. Once a Core EIP has been implemented in at least three clients, and all pass a common set of test suites, the status of the EIP is updated to 'Final'. An EIP can also be assigned status “Deferred”. The EIP author or editor can assign the EIP this status when no progress is being made on the EIP. |
There was a problem hiding this comment.
I'm assuming that only EIPs that are in a Final state are actually included in a hard fork, although this isn't explicitly stated here.
Is there a process where Accepted EIPs that are planned to be included in a hard fork are removed from inclusion for any reason? It might be helpful to elaborate on that.
There was a problem hiding this comment.
Whether an EIP ends up in a particular hard fork is down to whether it's in the "Hard fork meta" EIP for that HF. Suggestions on wording for documenting that are welcome.
EIPS/eip-1.md
Outdated
|
|
||
| For an EIP to be accepted it must meet certain minimum criteria. 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. The EIP editor will not unreasonably deny an EIP. Reasons for denying EIP status include duplication of effort, being technically unsound, not providing proper motivation, or failing to address backwards compatibility. | ||
|
|
||
| Once an EIP is marked Final, edits are not permitted unless they correct errata; no substantive changes may be made. Anyone wishing to amend a Final EIP must submit a new EIP instead. | ||
|
|
||
| An EIP can also be “Rejected”. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. | ||
|
|
There was a problem hiding this comment.
Who Rejects an EIP? The core devs? And who Withdraws an EIP? The author? This is the point at which I've suggested an EIP either goes to Deferred, Withdrawn, or Ready. Ready means the editors and authors agree the Draft is ready for consideration by the core devs. It's also at this point that the Fellowship's consensus becomes relevant. Seems we editors and the author can choose whether to take that consensus as just input, or to respect it as a matter of policy.
There was a problem hiding this comment.
Good question RE rejection; I don't know.
I don't think Ready is necessary as a formal status; it's ready when the author asks it to be added to an All Core Devs agenda.
|
Implemented in >=3 clients may be insufficient to describe that test. Additionally we want to know if 50%+ of clients have adopted the code. |
|
Sure @fulldecent can you include this in #1100 ? |
|
@elenadimitrova Thank you, I am happy to work with you and get this into #1100. Could you please send the editable SVG/AI version? I would most appreciate if you can create a pull request into https://github.com/fulldecent/EIPs/blob/patch-11/EIPS/eip-1.md. |
|
@fulldecent this is now in fulldecent#3 |
|
@elenadimitrova I'm having trouble to open the file, any advice?
|
|
@fulldecent The |
|
Does it make sense to have a path that allows an EIP to move from draft to "no longer under consideration" after an extended time period in draft with no community support on moving it forward to Last Call? Perhaps a part of this process is a "last call" before closing to see if there is more discussion to be had The process for "no longer under consideration" would be to close the EIP (which can be re-opened at any time if interest renews), which reduces the amount of open EIPs to those under active community consideration. EDIT: "Withdrawn" or "Differed" may work for this. See @elenadimitrova's comment: Maybe we should update this flowchart? #956 (comment) |
|
I've made this same argument for a long time, and the last call process only strengthens it for me. Once a draft survives the last call I think our work is done, and the status of the draft should be (nearly) the same, regardless of whether it is a core EIP, and whatever we call it. (I would call it Ready.) What the core devs do with an EIP is not our responsibility. If we want to provide the service of tracking what they do then I'd say it's Accepted when the core devs say so--as in the proposal--but not Final until it's running on the mainnet and cannot be changed, only fixed. The problem is partly reflected in how tangled the flowchart gets towards the end. Seems the EIP process should be a box with the core devs outside of it. |
|
I do not support a two-weeks review to close an abandoned draft. This is because any mistakes are so easy to undo. Regarding the flowchart. Any flowchart is going to be messy, please see the updated EIP1 as a way to document the process flow. Could you please rebase this PR ? |
@fulldecent I strongly disagree with you on that. Not every flowchart is messy, in fact the good ones aren't. A messy flowchart has the added benefit of localising a problem in the process that needs reworking, that's all. On a similar note you asked me to submit a PR and I did 22 days ago.. fulldecent#3 and here we are still having this conversation. How can we get this to a close? |
|
I have your file but I can't open it. I need an editable SVG file to work with the flow chart. Correction: any flowchart on this process is going to be messy. And I can help make it if there is an appetite for such a detailed and accurate diagram. |
Why an
Besides yourself, pretty much everyone else involved in the discussions here has shown "appetite" for diagramming the process. You however seem to prefer ascii "flowcharts" so I've closed that PR. @Arachnid Shall I just submit a PR to your branch of this EIP or a separate one altogether for adding the diagram in as it was already agreed here? |
|
svg is a portable and open format. It is the preferred format for sharing non-photo graphics in open projects. VSD is a proprietary graphics format that most devices are not capable of using. |
|
Same diagram in an svg format but zipped so we agree with GH |
|
@elenadimitrova, |
|
Thanks for the feedback @loredanacirstea , updated version below. Also on the state transition when a Core EIP gets rejected at the "Core devs meeting review", should the status be directly set to |
|
This scope of change is this PR is small and no longer includes changing from the existing wording around "ethereum philosophy". I support to merge as is and continue to make progress and discuss other things in new PRs. |
|
Well @Arachnid would need to rebase/fix conflicts. |
|
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. |
Simple Summary
This EIP specifies a new process for the lifecycle of EIPs, focusing on the acceptance and approval of drafts.
Motivation
The process for the EIP lifecycle defined in EIP-1 is ambiguous, failing to clearly specify when draft EIPs should be merged by editors, and what the process is for progressing a draft EIP, particularly an ERC, from draft to final status. This EIP proposes to revise the process by providing more concrete criteria and a simpler process for draft acceptance.
Rationale
This proposal serves to describe more clearly the present process for acceptance and implementation of Core EIPs, while also proposing a more concrete process for non-core EIPs. This serves to alleviate EIP editor workload in cases where manual approval is not necessary, and ensures that outstanding pull requests will all represent work required by the editors, making it easier to identify what actions are required, and making the approval process more transparent to users.