Hegotá Scoping Timeline
Following the Glamsterdam scoping process, I’d propose the following approach for Hegotá scoping. This is a preliminary timeline that may see modifications pending the Fusaka retrospective and any further process improvements we find as we finish getting Glamsterdam to mainnet.
- [Jan 8th - Feb 4th] Headliner Proposals
- During this period, headliner champions should be invited to present their proposals.
- Headliner champions must open an Ethereum Magicians thread with the hegota tag at least 48 hours before the ACD call on which they wish to present, including relevant information about their proposal. A template is found at the bottom of this post.
- Note: While technical readiness is a factor, an EIP is not required at this stage. For instance, a proposal focusing on “reducing disk requirements for nodes” is acceptable even without a specific EIP.
- This period should evaluate not only Core Dev preferences for the next upgrade but also broader community preferences. While ACD can provide feedback around which stakeholders should be consulted, headliner champions are responsible for gathering sufficient evidence of support.
- [Feb 5th - Feb 26th] Headliner discussion & Finalization
- Once candidate headliners are identified, ACD will spend the next month evaluating them, soliciting community feedback, and finalizing decisions on which feature(s) to prioritize for Hegotá.
- [30 days immediately following final headliner selection] Non-Headliner EIP Proposals
- Process will generally follow that listed in the Glamsterdam document.
- [TBD] Non-Headliner EIP CFI Decisions
- Process will generally follow that listed in the Glamsterdam document.
- [TBD] CFI → SFI EIP Decisions
- Process will generally follow that listed in the Glamsterdam document.
Headliner Proposal Template
Create the post in the EIPs category with the title “Hegota Headliner Proposal: [title of EIP]” and tag the post with the hegota tag.
-
Summary (ELI5): Concise, plain-language explanation of the proposal, why it matters, and who directly benefits.
-
Champion: point-of-contact for the EIP
-
Detailed Justification:
-
What primary and secondary benefits exist, ideally supported by data or clear rationale?
-
Clearly articulate “Why now?”—Why prioritize this feature today?
-
Justify this specific approach compared to alternative solutions (considering lower risks, higher value).
-
-
Stakeholder Impact:
-
Positive: Identify beneficiaries clearly and document explicit support.
-
Negative: Identify potential negative impacts, document objections, and describe mitigations or accepted trade-offs.
-
-
Technical Readiness: Assess technical maturity clearly, providing links to specifications, tests, and client implementations.
-
Security & Open Questions: Document explicitly known security risks, open issues, or unclear aspects. Include threat models, preliminary audit plans, or next steps.