ethereum/EIPs-1

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md

介绍了什么是EIP等等的详细信息：

eip	title	status	type	author	created
1	EIP Purpose and Guidelines	Active	Meta	Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, and others https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md	2015-10-27, 2017-02-01

EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature.

EIP Types

There are three types of EIP:

• A Standard Track EIP describes any change that affects most or all Ethereum implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories. Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification.
  • Core - improvements requiring a consensus fork (e.g. EIP5, EIP101), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, EIP90, and the miner/node strategy changes 2, 3, and 4 of EIP86).
  • Networking - includes improvements around devp2p (EIP8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.
  • Interface - includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP59, EIP6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
  • ERC - application-level standards and conventions, including contract standards such as token standards (ERC20), name registries (ERC26, ERC137), URI schemes (ERC67), library/package formats (EIP82), and wallet formats (EIP75, EIP85).ERC是应用水平的标准和惯例
  • 而你会看到EIP定义或讨论的问题里，常常会看到它相关的ERC，也就是，讨论过程中，有一些要征求更多人意见时，就会把它放在细节定义放在ERC里。而且他们会用一个号码，比如ERC-20就是对应到EIP-20。
  • 简单讲，讨论项目，一开始会用EIP提出建议，结果与细节会定义在ERC，最后会final（拍板定案），放在EIP清单里定稿EIPs
• An Informational EIP describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. （只提供信息）Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.
• A Meta EIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.

It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn't require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.

An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

EIP Work Flow

就是这个建议现在完成到什么情况了

Parties involved in the process are you, the champion or EIP author, the EIP editors, and the Ethereum Core Developers.

⚠️ 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 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:

[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

Each status change is requested by the EIP author and reviewed by the EIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your EIP. The EIP editors will process these requests as per the conditions below.

• 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.当你PR一个建议时，它的状态就是WIP
  • ➡️ 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.
  • ❌ 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.
• Draft -- Once the first draft has been merged,（当该draft被合并后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).
  • ➡️ Last Call -- If agreeable, the EIP editor will assign Last Call status and set a review end date, normally 14 days later.
  • ❌ 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.
• Last Call -- This EIP will listed prominently on the http://eips.ethereum.org/ website (subscribe via RSS at last-call.xml).
  • ❌ -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the EIP to revert to Draft.
  • ➡️ Accepted (Core EIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.
  • ➡️ Final (Not core EIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
• Accepted (Core EIPs only) -- This EIP is in the hands of the Ethereum client developers. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process.
  • ➡️ Final -- Standards Track Core EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.
• Final -- This EIP represents the current state-of-the-art. A Final EIP should only be updated to correct errata.

Other exceptional statuses include:

• Deferred -- This is for core EIPs that have been put off for a future hard fork.
• Rejected -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented.
• Active -- This is similar to Final, but denotes an EIP which which may be updated without changing its EIP number.
• Superseded -- An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP.

当然还有其他的一些内容，再自己看吧