Update EIP-7723: Update eip-7723.md#11006
Conversation
Added edits for clarity and replaced "Status" with "Stages" as needed.
File
|
| All EIP stages apply to a single network upgrade. EIPs must be `Proposed`, `Considered`, `Declined` or `Scheduled` separately for each network upgrade. While an EIP cannot be `Included` in two network upgrades, an EIP being `Declined for Inclusion` in a previous upgrade does not prevent it from being `Proposed`, `Considered`, `Declined` or `Scheduled` for inclusion in any future upgrade. | ||
|
|
||
| The statuses below are generally defined for Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these statuses. The differences in the process and implications for non-Core EIPs are noted in each status definition. | ||
| The stages below are generally defined for Standards Track-Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition. |
There was a problem hiding this comment.
| The stages below are generally defined for Standards Track-Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition. | |
| The stages below are generally defined for Standards Track: Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these stages. The differences in the process and implications for non-Core EIPs are noted in each stage's definition. |
I would leave as is, but if the prefix is needed, should it be a colon.
There was a problem hiding this comment.
I’d lean toward using “Standards Track – Core”.
From what I’ve seen, there isn’t a canonical reference (including in EIP-1) that specifies combining Type and Category with a colon. They’re defined as separate fields, so any combined representation is more of a UI/formatting choice than a spec requirement.
Using “–” feels clearer and more neutral - it reads well, avoids implying a strict hierarchy, and works better in dashboards and labels. So unless there’s a strong convention we want to follow elsewhere, I’d prefer sticking with “-” for consistency.
| To propose an EIP for inclusion, someone **MUST** open a pull request to add it to the `Proposed for Inclusion` section of the Upgrade Meta EIP. The proposer of an EIP **SHOULD** serve as the primary point of contact for that EIP for the duration of the upgrade cycle or **SHOULD** designate another person to serve in that role. Reasonable pull requests **SHOULD** be merged in a timely fashion by the Upgrade Meta EIP author. | ||
|
|
||
| At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the next upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated. | ||
| At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated. |
There was a problem hiding this comment.
| At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated. | |
| At this stage, implementation teams **SHOULD** review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated. |
Sentence is about non-Core EIPs.
There was a problem hiding this comment.
“…supporting the EIP before the network upgrade is activated”
is a bit ambiguous. It could be read as non-Core EIPs being independently considered for inclusion, which isn’t the intent. The goal is to show that they support Core EIPs, not that they are themselves the primary subject of the upgrade.
Thus, I’d lean toward the first version:
“At this stage, implementation teams SHOULD review the EIP. For Core EIPs, this should be in the context of including it in the said upgrade. For non-Core EIPs, this should be in the context of supporting Core EIPs before the network upgrade is activated.”
This feels more correct because it clearly communicates why non-Core EIPs are included in the Meta EIP. Historically, Meta EIPs have focused on Core EIPs, and the inclusion of non-Core EIPs is primarily to indicate supporting dependencies, not to position them as standalone targets for inclusion in the upgrade.
Resolving review comments
Added edits for clarity and replaced "Status" with "Stages" as needed.