---
eip: 9999
title: Working Group Charter - EIPs
description: Organizational structure and guidelines for proposals related to the EIP process itself.
author: Sam Wilson (@SamWilsn)
discussions-to: https://...
working-group: eips
status: Living
type: Working Group
---

## Introduction

The EIPs Working Group develops and publishes Ethereum Improvement Proposals (EIPs) related to the EIP process itself. It comprises the EIP Editors, and follows their decision making process.

## Scope

Any proposal that modifies, clarifies, or is of interest to EIP Editors or authors belongs in this Working Group. This includes the EIP Editor and Working Group charters, guidelines on the content of proposals, style guides, and other sundry items.

## Workflow

The workflow for proposals under the EIPs Working Group is as follows:

digraph Workflow {
    ratio = 0.2;
    
    Withdrawn [peripheries=2];
    Final [peripheries=2];
    Superseded [peripheries=2];
    Start [shape=point];
    
    {
        rank = "same";
        Start;
        Draft;
        Superseded;
        Living;
        Final;
    }
    
    {
        rank = "max";
        Stagnant;
        Withdrawn;
    }
    
    
    Start -> Draft;
    
    Draft -> Living;
    Draft -> Final;
    Draft -> Stagnant;
    
    Final -> Superseded;
    Final -> Withdrawn;
    
    Stagnant -> Draft;
    
    Stagnant -> Withdrawn;
    Living -> Withdrawn;
    Draft -> Withdrawn;
    

    Living -> Final [style=invis];
}

### Draft

The Draft status is the first formally tracked stage of an EIP in development. Draft proposals may be freely edited by their authors, and have not been ratified by the EIP Editors.

Draft proposals may progress to either Living or Final, depending on whether they are expected to evolve or remain immutable. If a Draft proposal goes too long without an update, it may be moved to Stagnant.

### Living

Proposals in the Living status have been ratified by the EIP Editors. Unlike proposals in the Final status, Living proposals are expected to change over time. Changes to Living proposals must be approved by EIP Editors.

Living proposals may be moved to Withdrawn.

### Final

Final proposals have been ratified by the EIP Editors, and may not be edited except for errata, clarification, formatting changes, and to supersede or withdraw them. Changes to Final proposals must be approved by EIP Editors.

Final proposals may be moved to Withdrawn or Superseded.

### Stagnant

Draft proposals that have not be updated for some time may be moved to Stagnant without approval from authors. Changes to Stagnant proposals must be approved by EIP Editors.

Stagnant proposals may be moved to Draft or Withdrawn.

### Withdrawn

Proposals in the Withdrawn status are no longer in development and are not in effect. This can happen if an author no longer wishes to pursue a proposal, or if EIP Editors revoke a proposal. If a proposal is being replaced, prefer Superseded instead. Withdrawn proposals cannot be changed.

Once withdrawn, proposals cannot be moved to another status.

### Superseded

Superseded proposals are no longer in effect and have been replaced with a new proposal. Superseded proposals cannot be changed.

Once superseded, proposals cannot be moved to another status.

## Proposals

See [EIP-5069] for the general requirements.

### Preamble

Immediately following the headers defined in [EIP-5069], proposals in this Working Group must include: `type`. They may include `superseded-by` and `withdrawal-reason` as described below.

#### Header: `type`

The kind or category of proposal. Must be one of the values listed here.

For example:

type: Working Group

##### Type: `Working Group`

A proposal defining a Working Group, its proposal guidelines, and organization details.

#### Header: `superseded-by`

A comma separated list of EIP numbers that have replaced this proposal. Only permitted in, and is required for, Superseded proposals.

#### Header: `withdrawal-reason`

A short sentence explaining why this proposal was withdrawn. Only permitted in, and is required for, Withdrawn proposals.

### Body

The format of a proposal depends on the value of its `type` header.

#### Working Groups

When a proposal's `type` header is `Working Group`, the body must adhere to the following guidelines.

##### Sections

###### Introduction

_Required_. The introduction should be a brief overview of the contents of the Working Group charter. Someone reading this section should have an idea of the scope, organization structure, membership rules, and decision making processes of the Working Group being defined. The introduction should not be more than a paragraph.

###### Scope

_Required_. This section should clearly and unambiguously define the topics of proposals that this Working Group oversees. A Working Group should choose a single topic, or a few naturally related ones.

The scope should set out how an author decides if a proposal belongs in this Working Group. Prefer objective criteria over subjective ones whenever possible, though doing so might not always be possible. Examples are always helpful.

Some examples of good inclusion criteria are:

| Criteria | Description | Examples |
| ----------------- | ----------------------------------------------- | ------------------------------------ |
| Intended Audience | Who is expected to read/implement the proposal? | solidity developers, core developers |
| Technology Layer | Where will implementations run/exist? | social, Linux, EVM |

On the other hand, some examples of poor inclusion criteria might be:

- Specific Technologies (eg. JSON-RPC, ECDSA)
- Source of Proposal (eg. only proposals written by Company XYZ)
- Personal Interest (eg. "This is boring, take it to another Working Group.")

###### Workflow

_Required_. The workflow section defines how a proposal moves through a Working Group. A workflow is made of statuses (at least one mutable and one immutable.) This section should include a state diagram, and must include explanations of each status, how proposals move between statuses, and the expectations of authors and Working Group members at each status. Each status must be either _mutable_ (can be changed, stewarded by the Working Group) or _immutable_ (only specific changes, stewarded by EIP Editors.)

###### Proposals

_Required_. Preamble and content guidelines for proposals in a Working Group are defined in this section. For example, permitted origins for external references (see [EIP-5757]), allowed preamble fields, and optional/required section headings all belong here.

###### Membership

_Required_. This section defines who can be a member of the Working Group, and any expectations of members. Note that the actual process for approving/removing members belongs in the "Making Decisions" section, if such a process is defined.

###### Making Decisions

_Required_. The Making Decisions section sets out the procedure this Working Group uses to come to agreement. This procedure can be as simple as unanimity, or a complex series of on-chain token votes. Working Groups should prioritize practicality and shipping documents over onerous bureaucracy, while keeping the EIP mission in mind.

###### Copyright

_Required_. Every Working Group document must include a copyright section describing the license provided by the authors.

## Membership

The members of the EIPs Working Group are always exactly the EIP Editors.

## Making Decisions

Decisions made by the EIPs Working Group follow the same decision making process as the EIP Editors.

## Copyright

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

[EIP-5757]: https://eips.ethereum.org/EIPS/eip-5757