Skip to content

Commit

Permalink
Replace handbook with charter
Browse files Browse the repository at this point in the history
  • Loading branch information
SamWilsn committed Aug 9, 2023
1 parent ff3ec32 commit 6bfa4b4
Showing 1 changed file with 104 additions and 21 deletions.
125 changes: 104 additions & 21 deletions EIPS/eip-5069.md
Original file line number Diff line number Diff line change
@@ -1,44 +1,127 @@
---
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
type: Meta
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.

- Good communication skills
- Ability to handle contentious discourse
- 1-5 spare hours per week
- **Upholding Quality**: Upholding a measure of minimally-subjective quality for each proposal as defined by its target audience.

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.
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

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.

## Copyright
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!

Copyright and related rights waived via [CC0](../LICENSE.md).
## Structure

### EIP Editors

We, the Editors, consist of some number of EIP Editors and one Janitor elected by and from the EIP Editors.

EIP Editors are responsible for governing the EIP process itself, electing a Janitor, and stewarding proposals in semi-mutable and immutable statuses.

The Janitor's two responsibilities (above 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.

### Topic Groups

Topic Groups are semi-autonomous bodies focused on proposals related to specific topics or areas. They are bound by the policies set by the EIP Editors, but otherwise are responsible for defining their own governance, membership, and workflows. Topic Groups steward proposals not in semi-mutable or immutable statuses.

EIP Editors may be members of Topic Groups, though their editorship does not imply any special privilege in the Topic Group.

The EIP Editors may create or disband Topic Groups as needed, and Topic Groups are free to separate from this organization at any time.

## Conflict Resolution

Aside from defining reasonable policies, EIP Editors cannot interfere in the day-to-day running of a Topic Group.

## 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.

Membership requirements for Topic Groups are defined in their respective charters.

## 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 Janitor, 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

Initially, to establish a valid quorum, all EIP Editors must express their opinion (or vote where appropriate) 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 Janitor

Any EIP Editor can call for an election for Janitor. The EIP Editor with the most votes once quorum is met is named Janitor until the next election completes. If there is a tie, we'll randomly choose between the EIP Editors with the most votes. Business continues as usual while the election is running.

##### Adding an EIP Editor

An EIP Editor is added once quorum is met, provided no current EIP Editor objects.

##### Removing an EIP Editor

An EIP Editor is removed once quorum is met, provided no current EIP Editor (aside from the one being removed) objects. If the removed Editor was also the Janitor, an election for a new Janitor 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 Janitor to determine if rough consensus has been reached. Every EIP Editor is entitled to have their opinion heard and understood before the Janitor makes that determination.

No one, not the EIP Editors and certainly not the Janitor, 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]._

[RFC 2418]: https://www.rfc-editor.org/rfc/rfc2418

0 comments on commit 6bfa4b4

Please sign in to comment.