-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update EIP-5069: Replace handbook with charter (#7468)
* Replace handbook with charter * Remove topic groups * Small grammar fix * Apply @Pandapip1's suggestions * Remove extra space * Update EIPS/eip-5069.md Co-authored-by: Gavin John <[email protected]> * s/Janitor/Keeper * Update eip-5069.md --------- Co-authored-by: Gavin John <[email protected]>
- Loading branch information
Showing
1 changed file
with
93 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,44 +1,119 @@ | ||
| --- | ||
| eip: 5069 | ||
| title: EIP Editor Handbook | ||
| description: Handy reference for EIP editors and those who want to become one | ||
| author: Pooja Ranjan (@poojaranjan), Gavin John (@Pandapip1) | ||
| description: Organizational structure, decision making process, and other EIP Editor odds and ends. | ||
| author: Pooja Ranjan (@poojaranjan), Gavin John (@Pandapip1), Sam Wilson (@SamWilsn), et al. | ||
| discussions-to: https://ethereum-magicians.org/t/pr-5069-eip-editor-handbook/9137 | ||
| status: Living | ||
| type: Informational | ||
| created: 2022-05-02 | ||
| requires: 1 | ||
| --- | ||
|
|
||
| ## Abstract | ||
| ## Introduction | ||
|
|
||
| An Ethereum Improvement Proposal (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 standardization process is a mechanism for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because improvement proposals are key components of Ethereum blockchain, it is important that they are well reviewed before reaching `Final` status. EIPs are stored in text files in a versioned repository which is monitored by the EIP editors. | ||
| 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. | ||
|
|
||
| This EIP describes the recommended process for becoming an EIP editor. | ||
| ## Mission | ||
|
|
||
| ## Specification | ||
| ### What we Do | ||
|
|
||
| ### Application and Onboarding Process | ||
| Our mission is to serve the broad Ethereum community, both present and future, by: | ||
|
|
||
| Anyone having 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. Potential EIP editors should have the following skills: | ||
| - **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. | ||
|
|
||
| - Good communication skills | ||
| - Ability to handle contentious discourse | ||
| - 1-5 spare hours per week | ||
| By adhering to defined criteria, we promote the development of high-quality and relevant proposals that drive the evolution of Ethereum. | ||
|
|
||
| The best available resource to understand the EIP process is [EIP-1](./eip-1.md). Anyone desirous of becoming an EIP editor MUST understand this document. Afterwards, participating in the EIP process by commenting on and suggesting improvements to PRs and issues will familliarize the procedure, and is recommended. The contributions of newer editors should be monitored by other EIP editors. | ||
| ### What we Don't | ||
|
|
||
| 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](./eip-1.md). If every existing EIP editor approves, the author becomes a full EIP editor. This should notify the editor of relevant new proposals submitted in the EIPs repository, and they should review and merge those pull requests. | ||
| On the other hand, we do _not_: | ||
|
|
||
| ### Special Merging Rules for this EIP | ||
| - **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. | ||
|
|
||
| This EIP MUST have the same rules regarding changes as [EIP-1](./eip-1.md). | ||
| - **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. | ||
|
|
||
| ## Rationale | ||
| - **Manage**: We do not track implementation status, schedule work, or set fork dates or contents. | ||
|
|
||
| - "6 months" was chosen as the cutoff for denoting `Stagnant` EIPs terminally-`Stagnant` arbitrarily. | ||
| - This EIP requires special merging rules for the same reason [EIP-1](./eip-1.md) does. | ||
| - **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 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. | ||
|
|
||
| ##### 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](../LICENSE.md). | ||
|
|
||
| [RFC 2418]: https://www.rfc-editor.org/rfc/rfc2418 |