Add EIP-5976: Handbook for EIP Authors

.github/workflows/ci.yml

@@ -103,7 +103,7 @@ jobs:
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
-          unchecked: 1, 5069, 5757
+          unchecked: 1, 5069, 5757, 5976
 
   markdownlint:
     name: Markdown Linter

EIPS/eip-5976.md

@@ -0,0 +1,63 @@
+---
+eip: 5976
+title: EIP Author Handbook
+description: Handy reference for EIP authors with specific suggestions of best practice
+author: Zainan Victor Zhou (@xinbenlv)
+discussions-to: https://ethereum-magicians.org/t/informational-eip-author-handbook/11754
+status: Draft
+type: Informational
+created: 2022-11-15
+---
+
+## Abstract
+
+A handy reference for EIP authors with specific suggestions of best practices for different kinds of EIPs.
+
+## Specification
+
+### Scoping
+
+1. Standard track EIPs are divided in 4 categories: Core, Network, Interface, and ERC (Application). A new EIP should only address one category, although ERCs may occasionally make Interface-category changes (a good example is [EIP-3668](./eip-3668.md).
+
+### Identifying Related and Competing EIPs
+
+1. Authors of new EIPs should familiarize themselves with related EIPs.
+2. EIPs must mention strict dependencies on other EIPs in the Specification section and and `requires` field in the EIP preamble.
+3. EIPs should mention how existing EIPs could cause unexpected interactions.
+4. EIPs should describe, in the Motivation section, how the EIP compares to competing EIPs (with a focus on how the EIP addresses different areas or uses than existing EIPs). In addition, EIPs should describe, in the Rationale section, how design decisions compare to competing EIPs.
+
+### The EIP Process
+
+1. EIPs should move to Review once a significant amount of discussion has occurred and consensus has been reached, either by edits to the EIP or the creation of a new competing EIP. It is recommended that this discussion occur on FEM and/or be linked in the FEM discussion.
+2. Non-core EIPs should move to last call when two or more independently-built compliant implementations have been created. Core EIPs should move to last call when they are proposed for a fork. Make sure to have it thoroughly proofread by at least one author and one non-author, as major mistakes (as with [EIP-712](./eip-712.md) and [EIP-1363](./eip-1363.md)) might not be possible to correct once the EIP moves to final.
+3. Non-core EIPs should move to final as soon as their last call deadline is reached, as long as there remains no contentious discssion.
+
+### ERC EIPs
+
+#### Worthiness of ERC EIPs
+
+1. New ERC EIPs is RECOMMENDED to justify its "worthiness" by providing in its Rationale section:
+
+- A _massive pre-standardized adoptions_, e.g [EIP-721 Non-Fungible Token](./eip-721.md).
+- A _strong potential demand as seen elsewhere_, but couldn't yet be achieved on EVM due to lacking API consensus [EIP-137 Ethereum Domain Name Service](./eip-137.md).
+- A _novel use cases backed_ by interested future adopters., e.g. [EIP-4337](./eip-4337.md).
+
+### Core EIPs
+
+#### When requiring a hard-fork
+
+1. A new EIP requiring a hard-fork is RECOMMENDED to explicitly declare a place-holding number as a named parameter and recommend implementing clients to use such name as controlling parameter prior to rollout.
+
+#### When adding a new EVM instruction
+
+For a new EIP that adds a new EVM Opcode/Instruction:
+
+
+- Its `type` MUST be `Standards Track` and its `category` MUST be `Core`.
+- It MUST specify a mnemonic (such as `BASEFEE` for [EIP-3198](./eip-3198.md)).
+- It MUST specify a placeholder opcode number, which MUST be clearly indicated as subject to change until the EIP nears finalization. When reviewing the opcode number, authors MUST check other instruction-adding EIPs to avoid picking a conflicting opcode.
+- It MUST specify a gas cost. It MUST justify its gas cost choice in its Rationale section.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).