Reword README

[fulldecent]

This borrows HEAVILY from https://github.com/apple/swift-evolution/blob/master/README.md and https://github.com/apple/swift-evolution/blob/master/process.md which is a mature and well-respected process from Apple. The difference is that they are a community with parties that set direction; but nobody/everybody sets direction for the Ethereum community.

Overview of changes proposed in this PR:

• Sets project goal
• Achieving "Final" status in this repository only represents that a proposal has been reviewed for technical accuracy. @MicahZoltu @Arachnid Did I finally get that right?
• Endorses EM as the place to discuss stuff BEFORE making a proposal

Work plan

• Merge this PR
• Disable the GitHub Issues feature on this repository, every "issue" I see here is actually something that should be discussed on EM
• Proceed with Changes EIP-1 wording to focus on technicals not community sentiment. #1224

[MicahZoltu]

I have become convinced by Nick that the EIP should be a mechanism for standards only, unrelated to deployments. In such a scheme, there would be no involvement from the core dev team and no step in the process would depend on them doing something (such as implementing, deploying, scheduling a hard fork, etc.)

EIPs would reference FORK_BLOCK_NUMBER rather than CONSTANTINOPLE_BLOCK_NUMBER when necessary and the implementation requirement would not need to be completed by any specific client, just any client (e.g., someone's fork of go-ethereum, or pyethereum, or whatever).

I don't know if anyone other than Nick and I have bought into this change or not yet, and I have been waiting for my current EIP PR to get merged before undertaking that change (since unlike my current PR, it's intent is to change the process).

[fulldecent]

@MicahZoltu I have updated this PR consistent with your PR that was merged. Specifically I updated Core Dev -> Client Dev.

The goal of this PR is to make README.md reflect with our new reality.

There are always more improvements to make. But I believe this PR is mergeable for now.

[MicahZoltu]

I like Ethereum magicians, but I know some people don't like it. In the past, Gitter and GitHub issues have also been recommended for discussion prior to an EIP. Any reason not to include them here?

[fulldecent]

I myself don't like Ethereum Magicians. Only because email notifications aren't working.

But most importantly, we should recommend a single place where people can go to have in depth discussions about standards and improvements. And GitHub is not a forum so GitHub issues is probably not the correct place.

To be consistent, this issue also directly the repository owner to disable the Github Issues feature for this repository. Such is consistent with how Apple's Swift Evolution repository is governed. And I have borrowed ideas heavily from them -- including the two-week EIP review.

[fulldecent]

@MicahZoltu I have responded to each of your comments. May you please continue your review?

[fulldecent]

@MicahZoltu ping

[MicahZoltu]

There has been pushback in the past about "forcing" people to use ethereum-magicians forum. Consider weakening the language here to something like:

Before you initiate a pull request, please read the process document. Ideas should be thoroughly discussed prior to opening a pull request, such as on the Ethereum Magicians forums or in a GitHub issue in this repository.

[fulldecent]

Addressing the extreme quantity of low quality issues in this repo is still an issue. (Solution: close GitHub issues and refer to Ethereum Magicians.) But if that will slow this PR down, then I am happy to do it separately.

Updated in 6abedf8

[fulldecent]

Does this update address the issue?

[MicahZoltu]

Same comment as above, both these links go to the same place, despite hinting that they go to different places. Consider moving the leak to the lead-in sentence:

... proposals in two categories:

[fulldecent]

I have higher expectations for a future EIP-1. But unlike change the all.html, I will defer editing EIP-1 at this time.

I request a slight exception to the UX rule in this case.

[MicahZoltu]

A few minor editorial notes that I think should be addressed, but overall I am in alignment with the theme of this change (EIP is a standards process, not a political process).

[fulldecent]

Hello @Arachnid, may I please ask for your review on this version?

[Arachnid]

Why have you deleted all this explanatory text?

[fulldecent]

Currently the README.md is focused on telling people how to dump whatever questions or ideas are in their head as quickly as possible into an EIP, which is a proposal to tell everybody else about a change they should make.

The proposed README.md focuses instead on explaining what an EIP is and how people should be more disciplined before they think about starting one.

// Ideas stolen from https://github.com/apple/swift-evolution which has a very good change management process.

[fulldecent]

Here is an example of yet another person that came to the EIP repository to use it as a forum (that's bad) rather than a place to work on actual standards development to promote interoperability among actual products that are or will be deployed (that's good).

➡️ #1621

You can confirm by this focusing statement in that draft EIP:

"I would like to start a discussion here for the viability and the merit of the proposal as well as design."

---

I believe #1621 is wildly out of scope for this repository at this stage and wastes time for all parties involved. Instead, such exploratory discussion should be OUTSIDE of a standards setting like this. It should be on Reddit or wherever else.

We should make this clear to people when they first visit this repository. We can do this easily. Just merge this PR.

[axic]

@fulldecent @Arachnid what is the status of this PR?

[fulldecent]

@axic Thank you, I appreciate your updates to keep this up to date

[axic]

@fulldecent can you fix the conflicts please?

[fulldecent]

@axic resolved

[axic]

This is not highlighted in index.html nor EIP-1. I think ti should be added.

[axic]

This is not highlighted in index.html nor EIP-1. I think it should be added.

[fulldecent]

Specifications for the process should be in EIP-1. This information should be out of scope for the README.

[axic]

These are part of index.html and EIP-1.

[MicahZoltu]

2 years later and now an editor (rather than just an annoying commenter on the internet), I generally approve of this change, though I left a few notes that may be worth discussing/addressing before merge. Leaving this as a Comment rather than a Reject or Approve since I don't feel super strongly about any of them. The comment about Consensus/Other is the only one that really makes me hesitant to Approve this as "strictly better than what was here before".

[MicahZoltu]

What value do we get in making this distinction? Why is this distinction more valuable than the current Core, Network, Interface, ERC?

[fulldecent]

I believe the audience for README.md will be the wide community of Ethereum users. This includes people that will be coming by (driving by?) to make their opinions heard on the likes of the next contentious hard fork, as well as others that are implementers/developers.

I'm guessing that anybody who has more than one Ether for more than one or two years will have a strong opinion on The DAO fork, and maybe even the latest fork. But I'll bet that less than 50% would know if those were Core, Network, Interface, or ERC EIPs.

Therefore I have added this distinction in plain language so that the intended audience can easily understand what they are looking at.

[MicahZoltu]

I suspect that the number of people in the intersection of "drive by brigadier" and "stopped to read the Readme" and "didn't comprehend the categories" is small enough that it isn't worth adding complexity (another layer of abstraction) to the EIP process, EIPs page, etc.

[fulldecent]

We disagree on the target audience.

But we agree that this PR can go on without that part.

[MicahZoltu]

If you want to extract these two lines out into a separate PR we can merge this without being blocked by this discussion, and then we can have a more focused discussion on just this topic (with hopefully more people getting involved). I'm 👍 to merge everything else, but would like to discuss these lines in particular more before merging.

[MicahZoltu]

Note: I'm OK with the deletion above these two lines being part of this PR, even if these two lines aren't included in this PR. We would want to remove line 27 (of your branch) as well and pull it out to the new PR if we decide to go that route. So the new PR would only add the following, and this PR would remove the status description section (which really should be in EIP-1 only anyway).

We promote high-quality, peer-reviewed proposals in two categories:

• Consensus Changes require people running an Ethereum client to update their software to implement the change. If enough people do not upgrade then an existing network will fork into two separate networks.
• Other Proposals do not require a change in client software and can be used by any interested party.

[fulldecent]

Fixed at 922a1ab

[fulldecent]

@MicahZoltu thanks for the feedback, all your items replied and/or merged

[MicahZoltu]

Since this is a change to the Readme, I would like to get an approval from at least one other active editor, but I'm 👍 on this. @lightclient @axic do either of you have thoughts on these changes?

If we believe these changes are iteratively better than what is currently in the Readme, I propose we merge them and we can then iterate further afterward. If we think this is a step backward, then we should discuss further before merging.

[Souptacular]

LGTM. Great work simplifying this.

[lightclient]

This looks good. The validation section is out-of-date, but I can fix that in a separate PR.

[MicahZoltu]

Given this has been open for over 2 years I'm satisfied with 3 approvals. Going to merge this, we can always iterate on it later if other people have feedback.

[fulldecent]

Cool, thank you