EIP Editor Handbook
EIP-5069 is a proposal that outlines the recommended process for becoming an EIP editor. An EIP editor is responsible for reviewing and merging Ethereum Improvement Proposals (EIPs), which are design documents that provide information to the Ethereum community or describe new features for Ethereum or its processes or environment. The proposal states that anyone with a good understanding of the EIP standardization and network upgrade process, intermediate level experience on the core and/or application side of the Ethereum blockchain, and willingness to contribute to the process management may apply to become an EIP editor. The potential EIP editor should have good communication skills, the ability to handle contentious discourse, and 1-5 spare hours per week. The proposal recommends that anyone desirous of becoming an EIP editor should understand EIP-1, which is the Ethereum Improvement Proposal standardization process, and participate in the EIP process by commenting on and suggesting improvements to PRs and issues. The contributions of newer editors should be monitored by other EIP editors. Anyone meeting the above requirements may make a pull request adding themselves as an EIP editor and adding themselves to the editor list at config/eip-editors.yml and in EIP-1. If every existing EIP editor approves, the author becomes a full EIP editor. The proposal also provides guidelines for EIP titles, descriptions, and numbers, and recommends following RFC 2119 and RFC 8174 for terminology. The EIP Editor Handbook is a handy reference for EIP editors and those who want to become one.
Video
Original
Introduction
We, the Ethereum Improvement Proposal (EIP) Editors, maintain a repository of documents related to the Ethereum protocol and its ecosystem. Consider us both archivists making sure the community as a whole does not lose its history, and a publisher making sure interested parties can stay up-to-date with the latest proposals.
Mission
What we Do
Our mission is to serve the broad Ethereum community, both present and future, by:
-
Publishing Proposals: Making proposals, including their history and associated discussions available over the long term at no cost.
By doing so, we foster transparency and ensure that valuable insights from past proposals are accessible for future decision-making and learning.
-
Facilitating Discussion: Providing a forum for discussing proposals open to anyone who wants to participate civilly.
By encouraging open dialogue and collaboration, we aim to harness the collective knowledge and expertise of the Ethereum community in shaping proposals.
-
Upholding Quality: Upholding a measure of minimally-subjective quality for each proposal as defined by its target audience.
By adhering to defined criteria, we promote the development of high-quality and relevant proposals that drive the evolution of Ethereum.
What we Don't
On the other hand, we do not:
-
Decide Winners: If there are multiple competing proposals, we will publish all of them. We are not in the business of deciding what is the right path for Ethereum, nor do we believe that there is One True Way to satisfy a need.
-
Assert Correctness: While we might offer technical feedback from time to time, we are not experts nor do we vet every proposal in depth. Publishing a proposal is not an endorsement or a statement of technical soundness.
-
Manage: We do not track implementation status, schedule work, or set fork dates or contents.
-
Track Registries: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine.
-
Provide Legal Advice: Trademarks, copyrights, patents, prior art, and other legal matters are the responsibility of authors and implementers, not EIP Editors. We are not lawyers, and while we may occasionally make comments touching on these areas, we cannot guarantee any measure of correctness.
Documenting all of the things we would not do is impossible, and the above are just a few examples. We reserve the right to do less work whenever possible!
Structure
EIP Editors
We, the Editors, consist of some number of EIP Editors and one Keeper of Consensus (or just Keeper for short) elected by and from the EIP Editors.
EIP Editors are responsible for governing the EIP process itself, electing a Keeper, and stewarding proposals.
The Keeper's two responsibilities (on top of their EIP Editor duties) are: to determine when rough consensus has been reached on a matter, and determine when/if it is appropriate to re-open an already settled matter.
Membership
Anyone may apply to join as an EIP Editor. Specific eligibility requirements are left to individual current EIP Editors, but the general requirements are:
- A strong belief in the above mission;
- Proficiency with English (both written and spoken);
- Reading and critiquing EIPs;
- Participation in governance.
EIP Editors are expected to meet these requirements throughout their tenure, and not doing so is grounds for removal. Any member may delegate some or all of their responsibilities/powers to tools and/or to other people.
Making Decisions
Informally
For decisions that are unlikely to be controversial—especially for decisions affecting a single proposal—an EIP Editor may choose whatever option they deem appropriate in accordance with our mission.
Formally
Electing a Keeper, adding/removing EIP Editors, and any possibly-controversial decisions must all be made using variations of this formal process.
Preparation
Call for Input
For any matter requiring a decision, a call for input must be published in writing to the usual channels frequented by EIP Editors.
Quorum
Within thirty days of the call for input, to establish a valid quorum, all EIP Editors must express their opinion, vote (where appropriate), or lack thereof on the matter under consideration.
After thirty days from the call for input, if not all EIP Editors have responded, the quorum is reduced to the Editors that have responded. This deadline may be extended in exceptional situations.
Deciding
Electing a Keeper of Consensus
Any EIP Editor can call for an election for Keeper. Business continues as usual while the election is running. The EIP Editor with the most votes once quorum is met is named Keeper until the next election completes. If there is a tie, we'll randomly choose between the EIP Editors with the most votes, using a fair and agreed upon method (for example, a coin toss over a video call or a commit/reveal game of rock paper scissors.)
Adding an EIP Editor
An EIP Editor is added once quorum is met, provided the candidate consents and no current EIP Editor objects.
Removing an EIP Editor
An EIP Editor is involuntarily retired once quorum is met, provided no current EIP Editor (aside from the one being removed) objects. An EIP Editor may voluntarily leave their position at any time.
If the departing Editor was also the Keeper, an election for a new Keeper begins immediately.
Other Decisions
All other decisions are made through a "rough consensus" process. This does not require all EIP Editors to agree, although this is preferred. In general, the dominant view of the Editors shall prevail. Dominance, in this process, is not determined by persistence or volume but rather a more general sense of agreement. Note that 51% does not mean "rough consensus" has been reached, and 99% is better than rough. It is up to the Keeper to determine if rough consensus has been reached. Every EIP Editor is entitled to have their opinion heard and understood before the Keeper makes that determination.
No one, not the EIP Editors and certainly not the Keeper, holds veto powers (except when adding/removing an Editor as defined above.) It is imperative that the EIP process evolve, albeit cautiously.
This section has been adapted from RFC 2418.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all