# 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.
Last changed by  
 
SamWilsn
152

Read more

The Big List of EIP Peer Reviewers

This is a list of people/groups that have volunteered to be pinged on EIP discussion threads for specific topics. Forum Post There are four placeholders in the following template: As part of our process to encourage peer review, we assign a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @<!-- TODO -->! Please note that this review **is NOT required** to move your EIP through the process. When you&mdash;the authors&mdash;feel ready, just open a pull request. If any of this EIP's authors would like to participate in the volunteer peer review process, [shoot Sam a message](https://ethereum-magicians.org/new-message?username=SamWilsn&title=Peer+Review+Volunteer)! ---

4/27/2023
Execution Specifications: What is "Done"?

These things need to be implemented before the core spec code can be frozen: Issues in https://github.com/ethereum/execution-specs/milestone/14 [x] London [ ] The Merge [x] Opcode Refac [ ] Documentation Rendering [ ] https://github.com/ethereum/execution-specs/issues/590 [x] https://github.com/ethereum/execution-specs/issues/591

11/11/2022
Executable Spec instead of Core EIPs

Discussion link https://ethereum-magicians.org/t/core-eips-in-an-executable-spec-world/8640 Contents [toc] Context Today, Core EIPs are used to specify changes affecting the execution layer (EL) which need to be activated through coordinated network upgrades (a.k.a. soft/hard forks). Core EIPs currently serve two purposes: explaining the motivation/rationale/security implications of the change and formally specifying it. While the former is very useful, and helps the Ethereum community understand and debate changes, the latter isn't ideal for a few reasons:

3/23/2022
🅰️🅰️ Account Abstraction Beyond EIP-2938 🧵🎉

This is the second of two posts describing account abstraction. You can find the first post here. Special thanks to @adietrichs and the rest of the Quilt team for review, content, and editing! More Account Abstraction? If you haven't yet, read EIP-2938 Account Abstraction Explained for some background on account abstraction (AA) and how EIP-2938 implements it. To quickly summarize it here, EIP-2938 implements just enough AA to support single-tenant applications, with minimal consensus changes and some new transaction propagation rules. While the EIP lays the groundwork for AA and does provide a compelling solution for single-tenant use cases, like smart contract wallets, several use cases are not satisfied and require new features to be fully realized. Features Beyond EIP-2938

10/26/2020
Read more from SamWilsn
Published on HackMD