From 226b17b7e658077e879f4b2daab99dec5c5a2df1 Mon Sep 17 00:00:00 2001 From: Tim Beiko <9390255+timbeiko@users.noreply.github.com> Date: Wed, 4 Sep 2024 10:31:02 -0400 Subject: [PATCH] Update EIP-7723: MUST -> SHOULD Merged by EIP-Bot. --- EIPS/eip-7723.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-7723.md b/EIPS/eip-7723.md index ce9dfbdffdc01..3b97afc2e6d85 100644 --- a/EIPS/eip-7723.md +++ b/EIPS/eip-7723.md @@ -27,7 +27,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Context: Upgrade Meta EIPs -When planning a network upgrade, an Upgrade Meta EIP **MUST** be drafted 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 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 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`. @@ -43,13 +43,13 @@ Note that EIPs must be `Proposed for Inclusion` for each network upgrade. In oth ### Considered for Inclusion -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 **MUST** be updated to reflect this. +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. ### 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 **MUST** be updated to reflect this. +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.