ethereum
Update EIP-1: add Network Upgrade Inclusion
Adding 4 lines to reflect the new process discussed in https://ethereum-magicians.org/t/community-consensus-fork-headliners-acd-working-groups/24088 and https://eips.ethereum.org/EIPS/eip-7723
File EIPS/eip-1.md
Requires 2 more reviewers from @g11tech, @jochem-brouwer, @lightclient, @samwilsn, @xinbenlv
The scope for each upgrade is finalized within a few weeks of the previous fork going live on mainnet
i don't think this is enough of norm yet for it to be a hard-and-fast rule
Proposals do not carry over between upgrades—authors must re-propose their EIP for each upgrade cycle.
would suggest rewording to "All inclusion stages are fork-specific and EIPs must be re-proposed for any subsequent forks" to be a bit more specific, and generally getting rid of the em-dashes
And, more to scope, I think if it's going to include "network upgrade" instructions, it might deserve its own section, rather than being nested in the "EIP Work Flow" section, seems a little out of scope for that section
Thanks for commenting @nixorokish ,
i don't think this is enough of norm yet for it to be a hard-and-fast rule
Currently EIPs that are not proposed are not able to be discussed in ACDs so to me it's already an enforced "hard-and-fast rule". I do agree that the timing is unclear. Hence the wording "few weeks of the previous fork going live on mainnet" is the best I could find. Would be good to clarify that timing so that authors sticking to github can have the information needed to contribute to ethereum
to be a bit more specific, and generally getting rid of the em-dashes
I think em-dashes are okay when used appropriately. I have no strong opinion on this but I am convinced some people would like to see more of them !
this is not needed, EIP 7723 already describes this process and works on the top of EIP-1. the set of governance related EIPs could just be listed and browsed from eip website.
I am closing this PR but if you strongly feel about it, pls reopen it and then we can discuss this in an EIPIP meeting or via call to action cc @SamWilsn
@g11tech Yes I do feel strongly about it. It is the basis upon which the improvement process (BIP / PEP) have been built. The design ensures that anyone reading PEP-0001 or BIP-0001 can trace all process modifications, preventing fragmentation where rules exist in scattered documents. This design is enshrined in both PEP and BIP by having dedicated headers :
* Replaces: <pep number>
* Superseded-By: <pep number>
"PEPs can also be superseded by a different PEP, rendering the original obsolete." https://peps.python.org/pep-0001/
"BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete." https://bips.dev/2/
I don't understand what is the upside to not do that ? i.e not scattering the information in multiple documents without references (which obviously makes the task significantly harder for newer contributors). In its current form: EIPs that are not proposed as per EIP-7723 are not allowed to be discussed in ACDs which directly contradicts EIP-1's claim that "The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an AllCoreDevs agenda GitHub Issue."
How do we expect a new contributor (let's say from an academic background) to know about EIP 7723 ? I would like to get more eyes on the matter (e.g @SamWilsn @poojaranjan) ? I will try to make the case for the next EIPIP meeting.