What would happen if we could know that an EIP achieved something like all of the following?
Greater than 75% of voting core devs
Greater than 75% of voting miners.
Greater than 66% of voting quadratic ether [sqr(ether)]
Greater than 66% of voting popular consensus
How this is achieved, could be elsewhere, but such a simple specification could be done in EIP 1?
@MadeofTin The more I think about it, the more looking at proposals that cement the hard fork process into the EIP process seems like a bad idea. Creating informational proposals that guide Ethereum implementers (aka Core Devs) in how to implement network upgrades are nice, but I'm not sure our ever-changing implementation process should be wrapped up so deeply into our technical standardization process. I will be thinking about this a lot more, but I just wanted to mention this as I look at proposals like EIP 233 and EIP 2378 which deeply ingrains the "how" of what implementers do, when really those processes can exist either as informational standards or completely outside the standardization process (allowing for continuous improvement of these processes). I think perhaps what is missing is that we should have an "Ethereum Implementers Manual" which encodes these processes as largely separate from technical standards that implementers use to change the configuration of Ethereum Mainnet (and other Ethereum-based networks)
@fubuloubu We discussed this a little bit, in EIPIP3. I do agree that we should keep it out of EIP 1 because the upgrade process keeps changing and we don't want to edit EIP1 very often. At the same time, we need to point the community towards the current process being followed (probably via EIP1). So, I propose to add the "Motivation" section in Meta EIP for an upgrade. (This is missing from almost all of the previous Upgrade Meta EIP. However, it was added in the Muir Glacier upgrade Meta EIP.) In this section, say for Berlin EIP 2070 , we can add a reference to EIP 2378 that lists the EFI EIPs to be included. About EIP 233, I think that may be added to EIP 1 as a template (with small changes) for upgrade Meta EIP, where Meta EIP is defined. However, I think it should not be added until it's state is changed to 'Final/Accepted'. I also agree that both EIPs seem closer to Informational EIP than Meta EIP.
Big +1 on separating both concerns out. That’s something @Arachnid mentionned a few times on Twitter over the past weeks. I think it will be quite the effort to try and write this. I don’t have the bandwidth to take a stab at it but happy to help review/give feedback/etc. on any proposal. We should probably bring this up on the EIPIP meetings too to see if anyone else would like to help
Yeah, that's a good point.