Update EIP-7723: Add "Declined for Inclusion"

Merged by EIP-Bot.

EIPS/eip-7723.md

@@ -11,25 +11,23 @@ created: 2024-06-12
 
 ## Abstract
 
-Define the stages that Core EIPs go through in the process of planning network upgrades: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, and `Included`.
+Define the stages that Core EIPs go through in the process of planning network upgrades: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included`.
 
 ## Motivation
 
-When planning network upgrades, EIPs go through the `Considered for Inclusion` and `Included` stages. However, definitions for these terms are either outdated or non-existent. 
-
-Additionally, there isn't a formalized way for the Ethereum community to signal which EIPs they'd like to see included in a network upgrade, or for implementation teams to keep track of these. 
-
-This EIP proposes definitions for each of the following stages: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, and `Included`. It also provides context and guidelines around when and how EIPs should be moved from one stage to the next. 
+This EIP proposes definitions for the various stages EIPs go through when planning network upgrades. Specifically, these are: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included`. It also provides context and guidelines around when and how EIPs should be moved from one stage to the next. 
 
 ## Specification
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
+All EIP statuses defined in this EIP only apply within the context of a single network upgrade. In other words, EIPs are `Proposed`, `Considered`, `Declined` and/or `Scheduled` in the context of a specific 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. 
+
 ### Context: Upgrade Meta EIPs
 
-When planning a network upgrade, anyone **MAY** draft an Upgrade Meta EIP to list EIPs in various stages of consideration. This Meta EIP **SHOULD** include three categories in its specification section: `Proposed for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion`. Even if a category is empty, it **SHOULD** be included in the initial draft for clarity. 
+When planning a network upgrade, anyone **MAY** draft an Upgrade Meta EIP to list EIPs in various stages of consideration. This Meta EIP **SHOULD** include four categories in its specification section: `Proposed for Inclusion`, `Declined for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion`. Even if a category is empty, it **SHOULD** be included in the initial draft for clarity. 
 
-When the Upgrade Meta EIP is moved to `Last Call`, the `Proposed for Inclusion` and `Considered for Inclusion` lists **SHOULD** be removed, leaving only `Scheduled for Inclusion`. 
+When the Upgrade Meta EIP is moved to `Last Call`, the `Proposed for Inclusion`, `Declined for Inclusion` and `Considered for Inclusion` lists **SHOULD** be removed, leaving only `Scheduled for Inclusion`. 
 
 Before the Upgrade Meta EIP is moved to `Final`, the `Scheduled for Inclusion` stage **MUST** be renamed to `Included` and contain only EIPs that were activated in the upgrade. 
 
@@ -45,23 +43,29 @@ Note that EIPs must be `Proposed for Inclusion` for each network upgrade. In oth
 
 Once client developers have reviewed an EIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` stage. Once a decision is made by client teams to move an EIP to `Considered for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
 
-`Considered for Inclusion` signals that client developers are generally positive towards the EIP, and that, assuming it meets all the requirements for mainnet deployment, it **MAY** be included in the network upgrade. This stage is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to mainnet. An EIP **MAY** be removed from `Considered for Inclusion` if client teams are generally against including the EIP in the network upgrade. 
+`Considered for Inclusion` signals that client developers are generally positive towards the EIP, and that, assuming it meets all the requirements for mainnet deployment, it **MAY** be included in the network upgrade. This stage is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to mainnet. An EIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are generally against including the EIP in the network upgrade. 
+
+### Declined for Inclusion
+
+At any time during the network upgrade planning process, client developers **MAY** move EIPs from any other stage to the `Declined for Inclusion` stage if client teams are generally against including the EIP in the network upgrade. Once a decision is made by client teams to move an EIP to `Declined for Inclusion`, the Upgrade Meta EIP **SHOULD** be updated to reflect this.
+
+`Declined for Inclusion` signals that client developers wish to exclude the EIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An EIP which was `Declined for Inclusion` in a particular upgrade **MAY** still be `Proposed for Inclusion` in a subsequent upgrade. In exceptional circumstances, client developers **MAY** choose to move an EIP from `Declined for Inclusion` to `Considered for Inclusion` or `Scheduled for Inclusion`. 
 
 ### Scheduled for Inclusion 
 
 When client teams decide to work on an EIP as part of a network upgrade, the EIP **SHOULD** move to the `Scheduled for Inclusion` stage, and the Upgrade Meta EIP **SHOULD** be updated to reflect this. 
 
-`Scheduled for Inclusion` signals that implementation and testing work are underway, and that, assuming no issues arise as part of this process, the EIP **SHOULD** be included in the network upgrade. An EIP **MAY** be removed from `Scheduled for Inclusion` if client teams are generally against including the EIP in the network upgrade. 
+`Scheduled for Inclusion` signals that implementation and testing work are underway, and that, assuming no issues arise as part of this process, the EIP **SHOULD** be included in the network upgrade. An EIP **MAY** be moved from `Scheduled for Inclusion` to `Declined for Inclusion` if client teams are generally against including the EIP in the network upgrade. 
 
 ### Included
 
-Once a network upgrade has been activated, all EIPs that were part of the upgrade **MUST** be moved to `Included` in the Upgrade Meta EIP, and the `Proposed for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion` lists **MUST** be removed from the Meta EIP. 
+Once a network upgrade has been activated, all EIPs that were part of the upgrade **MUST** be moved to `Included` in the Upgrade Meta EIP, and the `Proposed for Inclusion`, `Considered for Inclusion`, `Declined for Inclusion` and `Scheduled for Inclusion` lists **MUST** be removed from the Meta EIP. 
 
 `Included` signals that the EIPs have been activated as part of the network upgrade. 
 
 ## Rationale
 
-Formalizing the `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, and `Included` stages provides better legibility to both Ethereum protocol maintainers and the community at large. 
+Formalizing the `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included` stages provides better legibility to both Ethereum protocol maintainers and the community at large. 
 
 The specification tries to minimize steps which **MUST** be followed to align with Ethereum's "rough consensus" governance model.