Conversation
| * **Work in progress (WIP)** -- Once the champion has asked the Ethereum community whether an idea has any chance of support, they will write a draft EIP as a [pull request]. Consider including an implementation if this will aid people in studying the EIP. | ||
| * :arrow_right: Draft -- If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP. | ||
| * :x: Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the [Ethereum philosophy](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy). | ||
| * :x: Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, not providing proper motivation or addressing backwards compatibility, or not in keeping with the [Ethereum philosophy](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy). |
There was a problem hiding this comment.
I don't see the need to remove this reason. I agree with seeing an EIP merged as Draft as soon as possible, but there are still standards like when a technical implementation makes no sense.
There was a problem hiding this comment.
@nicksavers The issue is that it puts more burden on editors, and encourages more discussion of a draft before it has a stable URL. IMO, we should be merging as soon as possible, as that way it has a stable URL and one place for discussions to go, instead of being fragmented across PRs.
There was a problem hiding this comment.
I agree with @nicksavers. Editors should make sure an EIP can be implemented as it is specified. What editors should refrain on is bikeshedding on multiple implementation/specification possibilities.
Anyone can just publish an EIP with the correct syntax but nonsense technical content.
There was a problem hiding this comment.
Maybe it is time to introduce another stage for EIPs? Draft, Complete, Accepted / Rejected
I agree that an EIP in draft stage should have a stable URL and there should be a way to gauge interest before writing a full specification. But I also have problems reading EIPs that clearly have gaps or even worse, being asked to state my opinion on them.
There was a problem hiding this comment.
@chriseth What would the semantics of this new stage be? It seems like it'd be the same as draft, the only difference is that the author is asking you to review it.
There was a problem hiding this comment.
I see Final Call as the stage in which the author signals that the proposal should not be in Draft anymore.
| Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm). | ||
|
|
||
| ### Suggestions for Authors | ||
| *The following are not requirements but are suggestions from the EIP Editors* |
There was a problem hiding this comment.
They are suggestions in order to get your proposal taken seriously. So it's somewhere in between requirements and suggestions.
|
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. |
6 participants
Removed language around Drafts not being merged due to being Technically unsound. This follows the principle that EIPs should be merged as early as possible.