Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifying Editor suggestions #2147

Closed
wants to merge 3 commits into from
Closed

Clarifying Editor suggestions #2147

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4345580
Merge pull request #7 from ethereum/master
MadeofTin May 24, 2019
df11f70
Added clarifications
MadeofTin Jun 25, 2019
a1ef220
Update eip-1.md
MadeofTin Jun 25, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion EIPS/eip-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,9 @@ An EIP must meet certain minimum criteria. It must be a clear and complete descr

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*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are suggestions in order to get your proposal taken seriously. So it's somewhere in between requirements and suggestions.


:warning: Before you begin, vet your idea, this will save you time. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (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.

Your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful EIP will move along:
Expand All @@ -52,7 +55,7 @@ Each status change is requested by the EIP author and reviewed by the EIP editor
* **Active** -- Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP).
* **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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Arachnid Arachnid Jun 27, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see Final Call as the stage in which the author signals that the proposal should not be in Draft anymore.

* **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
* :arrow_right: Last Call -- If agreeable, the EIP editor will assign Last Call status and set a review end date (`review-period-end`), normally 14 days later.
* :x: Last Call -- A request for Last Call status will be denied if material changes are still expected to be made to the draft. We hope that EIPs only enter Last Call once, so as to avoid unnecessary noise on the RSS feed.
Expand Down