AI Generated Meeting summary
Quick recap
The Ethereum Improvement Proposal Process (EIP) meeting #125 focused on reviewing call-for-input items, discussing editorial decisions, and showcasing community tools. The team discussed Call For Input 405 regarding “citation” status tags, with ongoing debate about whether to mark draft proposals or only final/living ones, and Issue 406 about informational EIPs and status, which requires more editor input. Greg’s informational EIP proposal about control flow was approved for merging as an informational EIP. Rito presented a new multi-repo local build system for the EIP working group, which streamlines local development across multiple repositories, though it still requires a 10-minute build time. The meeting also covered updates on EIP documentation format improvements and forced merge permissions for editors.
Next steps
- Pooja: Add Ben’s PRs to the agenda for next Tuesday’s office hour meeting
- Sam: Write a comment on the Issue 405 citation status PR and propose a solution for editors to review
- Editors: Review and comment on the Issue 405 citation status PR (to be done async before next meeting)
- Editors: Review and comment on EIP 7870 (hardware requirements) status discussion async and propose solutions for handling living vs final status for informational EIPs
- Sam: Review Rito’s multi-repo local build system PRs, starting tomorrow
- Rito: Consider breaking up the multi-repo local build system PR into smaller, stacked PRs to aid review
- Editors: Review the EIP review bot PR (David’s PR) and provide comments
- Sam: Follow up with DevOps about adding forced merge permissions for additional editors if needed
- Editors: Add documentation format for test cases and implementation references to the template.md or contribution.md by next meeting
- Rito: Follow up on ECH Institute’s Discord to schedule a demo session for the multi-repo local build system
- Editors: Book slots for hosting upcoming EIP editing office hours
- Editors: Review and provide input on the informational EIP (Greg’s proposal) before it is merged
Summary
EIP Meeting 125 Agenda Overview
Pooja clarified that Ben’s pull requests should be discussed in the office hours meeting rather than the current EIP meeting, and agreed to add them to next Tuesday’s office hour agenda. Rito confirmed he would introduce his community-built tool during the community feedback update section later in the meeting. The meeting began with Pooja welcoming participants and outlining the agenda for EIP Meeting Number 125, which included call for inputs, editor discussions, updates from previous meetings, and a community tool introduction.
EIP Citation Status Discussion
The team discussed several items including Unicode Technical Standards (393) which is awaiting approval on a pull request, and Matt’s EIP editor call for input (398) which has been affirmed. Sam reported that removing online serial from citation was completed and merged. The main discussion centered on EIP 405 regarding adding a status tag in citations, where Pooja explained the current draft shows all proposals as draft status regardless of their actual status. The team is debating whether citations should reflect the EIP status or use a different formula, with differing opinions on whether to include citations for final and living status proposals.
EIP Status Classification Discussion
The team discussed two main topics regarding EIPs and their statuses. First, they debated whether to include the “draft” status in citation markers, with Pooja suggesting avoiding “draft” to prevent confusion across different status indicators (page, preamble, and citation), while Sam proposed reserving “living” and “final” statuses without citations. The group agreed to let Sam draft a comment for further consideration. Second, Sam raised concerns about EIP 7870 being marked as “living” in the informational category, arguing that “living” status should be reserved for internal documents due to lack of approval process for living EIPs, potentially leading to eternally uneditable documents.
EIP Hardware Requirements Status Discussion
The team discussed whether an EIP regarding hardware requirements should remain a “living” proposal or be moved to “final” status. Sam expressed concern about the practical implications of keeping it as a living document, while Pooja and others debated the benefits of having current hardware recommendations clearly documented. The group agreed to continue the discussion asynchronously before making a decision, as no clear resolution emerged during the call. The meeting then transitioned to discussing Greg’s proposal about merging an informational EIP, with questions about how to handle references to this information in other core proposals (EIP-7979 and EIP-8013).
EIP Control Flow Discussion
The team discussed merging an informational proposal about control flow into the EIPs as an informational EIP rather than a core EIP due to its length. Greg expressed his strong preference for this approach, and after some discussion about formatting issues with Markdown references, the group agreed to proceed with merging it as an informational EIP. Pooja mentioned that the Ethereum Foundation developers had created issues and a pull request related to EIP number allocation, and she requested that Sam or others review these items.
EIP Working Group Progress Updates
The meeting focused on updates and discussions about the EIP (Ethereum Improvement Proposal) working group. Pooja and Sam discussed the progress on forced merge permissions for editors, confirming that Jochem now has the permission. They also addressed the need to document test cases and refresh implementation in a canonical place, deciding to add this information to the template.md file. Rito presented a new multi-repo local build system for the EIP working group, which aims to streamline local development and site building processes. Sam expressed excitement about reviewing the system and suggested breaking it into smaller PRs for easier review. The group also discussed the potential for adding a “required” section in future EIPs to alert implementers of dependencies on past EIPs, though they agreed this could be addressed through the new UI rather than adding a new field.