Merge a758465 into 8dd085d

.github/ISSUE_TEMPLATE.md

@@ -1,11 +1,11 @@
-ATTENTION! If you would like to submit an EIP and it has already been written as a draft (see the [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) for an example), please submit it as a [Pull Request](https://github.com/ethereum/EIPs/pulls).
+ATTENTION! If you would like to submit an ERC and it has already been written as a draft (see the [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) for an example), please submit it as a [Pull Request](https://github.com/ethereum/EIPs/pulls).
 
 If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion.  Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive.
 
 Keep in mind the following guidelines from [EIP-1](https://eips.ethereum.org/EIPS/eip-1):
 
-> 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. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.
+> Each ERC must have a champion - someone who writes the ERC using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is ERC-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.
 
-> Vetting an idea publicly before going as far as writing a 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.
+> Vetting an idea publicly before going as far as writing a ERC 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.
 
-> Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
+> Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft ERC should be presented as a Pull Request. This gives the author a chance to flesh out the draft ERC to make properly formatted, of high quality, and to address initial concerns about the proposal.

CNAME

@@ -1 +1 @@
-eips.ethereum.org
+ercs.ethereum.org

README.md

@@ -1,8 +1,10 @@
-# Ethereum Improvement Proposals (EIPs)
+# Ethereum Request for Comments (ERCs)
 
-The goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it. This repository tracks past and ongoing improvements to Ethereum in the form of Ethereum Improvement Proposals (EIPs). [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs are published.
+*Please note that ERCs were recently separated from the [EIPs](https://github.com/ethereum/eips) repo.*
 
-The [status page](https://eips.ethereum.org/) tracks and lists EIPs, which can be divided into the following categories:
+The goal of ERCs is to standardize and provide high-quality documentation for the Ethereum application layer. This repository tracks past and ongoing improvements application standards in the form of ERCs. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs and ERCs are published.
+
+The [status page](https://eips.ethereum.org/) tracks and lists both EIPs and ERCs, which can be divided into the following categories:
 
 - [Core EIPs](https://eips.ethereum.org/core) are improvements to the Ethereum consensus protocol.
 - [Networking EIPs](https://eips.ethereum.org/networking) specify the peer-to-peer networking layer of Ethereum.
@@ -11,73 +13,14 @@ The [status page](https://eips.ethereum.org/) tracks and lists EIPs, which can b
 - [Meta EIPs](https://eips.ethereum.org/meta) are miscellaneous improvements that nonetheless require some sort of consensus.
 - [Informational EIPs](https://eips.ethereum.org/informational) are non-standard improvements that do not require any form of consensus.
 
-**Before you write an EIP, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP process.**
+**Before you write an ERC, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP/ERC process.**
 
-Please note that this repository is for documenting standards and not for help implementing them. These types of inquiries should be directed to the [Ethereum Stack Exchange](https://ethereum.stackexchange.com). For specific questions and concerns regarding EIPs, it's best to comment on the relevant discussion thread of the EIP denoted by the `discussions-to` tag in the EIP's preamble.
+Please note that this repository is for documenting standards and not for help implementing them. These types of inquiries should be directed to the [Ethereum Stack Exchange](https://ethereum.stackexchange.com). For specific questions and concerns regarding ERCs, it's best to comment on the relevant discussion thread of the ERC denoted by the `discussions-to` tag in the ERC's preamble.
 
-If you would like to become an EIP Editor, please read [EIP-5069](./EIPS/eip-5069.md).
+If you would like to become an EIP Editor, please read [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069).
 
 ## Preferred Citation Format
 
-The canonical URL for an EIP that has achieved draft status at any point is at <https://eips.ethereum.org/>. For example, the canonical URL for EIP-1 is <https://eips.ethereum.org/EIPS/eip-1>.
+The canonical URL for an ERC that has achieved draft status at any point is at <https://eips.ethereum.org/>. For example, the canonical URL for EIP-1 is <https://eips.ethereum.org/EIPS/eip-1>.
 
 Consider any document not published at <https://eips.ethereum.org/> as a working paper. Additionally, consider published EIPs with a status of "draft", "review", or "last call" to be incomplete drafts, and note that their specification is likely to be subject to change.
-
-## Validation and Automerging
-
-All pull requests in this repository must pass automated checks before they can be automatically merged:
-
-- [eip-review-bot](https://github.com/ethereum/eip-review-bot/) determines when PRs can be automatically merged [^1]
-- EIP-1 rules are enforced using [`eipw`](https://github.com/ethereum/eipw)[^2]
-- HTML formatting and broken links are enforced using [HTMLProofer](https://github.com/gjtorikian/html-proofer)[^2]
-- Spelling is enforced with [CodeSpell](https://github.com/codespell-project/codespell)[^2]
-  - False positives sometimes occur. When this happens, please submit a PR editing [.codespell-whitelist](https://github.com/ethereum/EIPs/blob/master/config/.codespell-whitelist) and **ONLY** .codespell-whitelist
-- Markdown best practices are checked using [markdownlint](https://github.com/DavidAnson/markdownlint)[^2]
-
-[^1]: https://github.com/ethereum/EIPs/blob/master/.github/workflows/auto-review-bot.yml
-[^2]: https://github.com/ethereum/EIPs/blob/master/.github/workflows/ci.yml
-
-It is possible to run the EIP validator locally:
-
-```sh
-cargo install eipv
-eipv <INPUT FILE / DIRECTORY>
-```
-
-## Build the status page locally
-
-### Install prerequisites
-
-1. Open Terminal.
-
-2. Check whether you have Ruby 3.1.4 installed. Later [versions are not supported](https://stackoverflow.com/questions/14351272/undefined-method-exists-for-fileclass-nomethoderror).
-
-   ```sh
-   ruby --version
-   ```
-
-3. If you don't have Ruby installed, install Ruby 3.1.4.
-
-4. Install Bundler:
-
-   ```sh
-   gem install bundler
-   ```
-
-5. Install dependencies:
-
-   ```sh
-   bundle install
-   ```
-
-### Build your local Jekyll site
-
-1. Bundle assets and start the server:
-
-   ```sh
-   bundle exec jekyll serve
-   ```
-
-2. Preview your local Jekyll site in your web browser at `http://localhost:4000`.
-
-More information on Jekyll and GitHub Pages [here](https://docs.github.com/en/enterprise/2.14/user/articles/setting-up-your-github-pages-site-locally-with-jekyll).