# EIP Working Groups Proposal

This proposal sketches out how Working Groups _might_ work within the Ethereum Improvement Proposal ecosystem. It is frozen in time and is not updated, so it may not represent the current Working Group structure.

## Working Groups

### Definition

Generally, a working group is a group of experts working together to achieve specified goals.[^1] Here, the experts are people intimately familiar with a domain (like wallets, clients, DeFi, etc.) and the goals common to all of them include publishing and maintaining quality documents, and facilitating technical review/discussion.

EIP Working Groups can be long-lived ("standing") or temporary ("ad hoc"). Standing Working Groups deal with broad categories of proposals, while each ad hoc Working Group deals with a more specific topic and only exists until its stated goals (such as a specific set of proposals or outputs) are accomplished.

### Responsibilities

#### Upfront

A Working Group needs a charter, a public membership list, automated tooling for publishing documents, a public text-based forum, and assent from the EIP Editors before its members can start their day-to-day activities. Options for tooling (`eipw`, `eip-review-bot`, etc.) and a text-based forum (Ethereum Magicians) are provided by the EIP Editors.

The charter defines the scope of the Working Group, lays out how it operates, and defines the workflow of proposals under its purview. [Working Group Charter - EIPs](https://hackmd.io/@SamWilsn/BJTdMfA0n) is both an example of a charter and lays out in more depth the structure of and requirements for Working Group charters. A source of inspiration for such charters can be found [here][checklist].

Along with a charter, a newly formed Working Group must have an initial membership. It is recommended to have a current EIP Editor as an initial member. The membership may change over time, as defined in the Working Group's charter.

The EIP Editors provide some tooling (in the form of webpage rendering, linters, and GitHub bots) to make Working Groups easier to manage. Working Groups must either provide and maintain configurations for these tools, or make other arrangements to accomplish the same goals.

#### Ongoing

The primary responsibility of each Working Group is to review pull requests. Secondary responsibilities include performing any governance-related tasks (such as adding/removing members), providing resources for potential authors (akin to the EIP Editing Office Hours), and participating in discussions with EIP Editors regarding the EIP process.

Providing timely and constructive feedback on pull requests is the main reason why Working Groups exist. This feedback shall be based on the overarching guidance provided by Editors common to all Working Groups, any rules specific to each Working Group, and technical feedback (which should be provided on the discussion thread.) [^3] If a Working Group does not perform this responsibility, it is likely <!-- using "likely" instead of "can" to avoid the implication that this is the only reason to dissolve a WG --> to be dissolved by the EIP Editors.

In addition to the above, most Working Groups will have the occasional governance task to complete. These tasks include adding/removing members, deciding style/content guides, and many other tasks. [^4] How each Working Group addresses these items isn't formally defined, but potential Working Group members should probably expect semi-regular meetings and/or asynchronous discussion threads.

While more relevant for standing Working Groups, all Working Groups will likely want to maintain some documentation for proposal authors detailing the Working Group's process and style guides. Additionally, standing Working Groups might want to host regular Office Hours to help authors with any questions.

Finally, Working Groups are expected to provide input on process questions being discussed by the EIP Editors. This might take the form of pull request feedback for tooling changes, attending EIPIP meetings, or comments on Calls for Input.

## Changes

### Tooling

#### Repository Structure

Each Working Group will have its own repository, on GitHub, of the form `<organization>/eips-wg-<slug>`, where `<organization>` is replaced with a GitHub user (likely `ethereum` or `eips-wg`) and `<slug>` is replaced with a [slug] for the Working Group.

#### Pull Request Approval

For pull requests in mutable statuses (today's `Draft`, `Review`, and `Last Call`), Working Group members will have approval authority. For pull requests moving to or modifying a proposal in an immutable status (today's `Final`), EIP Editors will have sole approval authority.

#### Webpage Rendering

<!-- TODO -->

See https://github.com/eips-wg/ for now.

### Process

#### Credible Neutrality

The EIP process as a whole must remain credibly neutral. No special groups or individuals should get special treatment, and all rules and guidelines should be applied fairly. This includes everything from resisting corporate capture to not giving friends faster pull request reviews.

While the EIP process as a whole must be strictly neutral, Working Groups will have more freedom than EIP Editors do today. Should all Working Groups reject or deprioritize a proposal that would have been accepted today, EIP Editors are obligated to handle that proposal (possibly by creating a new Working Group.)

Today's process has a very low bar for acceptance: a vague sense of technical feasibility, enough detail for an implementation, and a reasonable possibility for multiple independent parties to have to interoperate. Standing Working Groups should maintain a similarly low bar, but ad hoc Working Groups may set stricter requirements (eg. commitments from multiple L2s, a working prototype, external audits, etc.)

#### Technical Review

Working Groups, especially ad hoc ones, are expected to provide more in-depth review than the EIP Editors do today. This should include technical feedback, willingness of the ecosystem to adopt the standard, and may include pretty much anything else.

[slug]: https://en.wikipedia.org/wiki/Clean_URL#Slug
[checklist]: https://learningproof.xyz/lifecycle-of-a-blockchain-standard/#checklist-for-a-succesful-specification-project

[^1]: https://en.wikipedia.org/w/index.php?title=Working_group&oldid=1189184623
[^3]: This is quite different from the current EIP process, where EIP Editors are only expected provide feedback on non-technical topics.
[^4]: See [previous EIPIP agendas](https://github.com/ethcatherders/EIPIP/issues?q=is%3Aissue+%22eipip+meeting%22) for what these tasks might look like.