| eip | title | description | author | discussions-to | status | type | created | requires |
|---|---|---|---|---|---|---|---|---|
5069 |
EIP Editor Handbook |
Organizational structure, decision making process, and other EIP Editor odds and ends. |
Pooja Ranjan (@poojaranjan), Gavin John (@Pandapip1), Sam Wilson (@SamWilsn), et al. |
Living |
Informational |
2022-05-02 |
1 |
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.
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.
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!
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.
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.
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.
Electing a Keeper, adding/removing EIP Editors, and any possibly-controversial decisions must all be made using variations of this formal process.
For any matter requiring a decision, a call for input must be published in writing to the usual channels frequented by EIP Editors.
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.
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.)
An EIP Editor is added once quorum is met, provided the candidate consents and no current EIP Editor objects.
An EIP Editor is forcibly removed 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.
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 and related rights waived via CC0.