Let’s get to know the current EIP process (as documented in EIP-1):

EIP-1: Purpose and guidelines for Ethereum Improvement Proposals

EIP Rational

We intend EIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum.

Three types of EIP

Standard Track EIP

Core

Networking

Interface

ERC - application-level standards and conventions

Informational EIP - design issue, or provides general guidelines or information to the Ethereum community Meta EIP - procedures, guidelines, changes to the decision-making process, and changes to the tools

EIP Work Flow

The EIP process begins with a new idea for Ethereum.

Each EIP must have a champion

A draft EIP should be presented as a pull request

Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification.

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.

Once an EIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”.

What belongs in a successful EIP?

Preamble

Simple Summary

Abstract

Motivation

Specification

Rationale

Backwards Compatibility

Test Cases

Implementations

Copyright Waiver

EIP Editor Responsibilities and Workflow

For each new EIP that comes in

Read the EIP to check if it is ready: sound and complete.

Edit the EIP for language

Once ready for the repository:

Assign an EIP number

Accept the corresponding pull request

List the EIP in README.md

The editors don’t pass judgment on EIPs. We merely do the administrative & editorial part.