I think the biggest value in a formal hardfork process is a schedule of events.
For a comparison to how another mature community handles this Java recently (2 years ago) went to a rapid release cadence, which for Java is every 6 months instead of every 2-3 years. The rapid release allows for features to slip a release when there is certainty that another release is fairly soon. Key to that is a schedule of dates where a feature must be ready or be dropped. Miss the train when it left the station? No worries another one is coming soon and at a fixed schedule. Java’s strict schedule is based on bugs and severity level - (https://openjdk.java.net/jeps/3). For us I think all features are the same level.
Based on Afri’s previous schedule (EEP-5: Ethereum Hardfork Process - request for collaboration) it would look something like
- T minus 20 weeks / 5 months - hard deadline to accept proposals for “Istanbul”
- T minus 12 weeks / 3 months - Client Implementations Due
- T minus 8 weeks / 2 months- Testnet Network Update
- T - Mainnet Network Update
It would be nice to add a “Finished EIPs for consideration due” at 24 weeks/6 months and “EIPs announce intent” sometime before that (28 weeks / 7 months)? For a notional Oct 2019 launch that would mean that EIPs are due in April and the hard cutoff is May. EIPs trying to get in should announce their intent in March, which is now.
If we do a 9 month cadence we have 2 months of quiet after the hard fork, or room to move the hard fork out if needed. At 6 months we would have an overlapping period between client implementations due and the network update.
This would give a deadline for the drivers of the EIPs to get ready for the hard fork and would provide certainty as to whether or not EIPs are going to be in the fork or not based on an impartial schedule.