Proposal of a formal process of selection of EIPs for hardforks (Meta EIP#)

The discussion started around March 2017 when Alex Beregszaszi (@axic) proposed Meta EIP 233: Formal process of hard forks to describe the formal process of preparing and activating hard forks.

In Dec 2018, Afri Schoedon proposed to write an EEP to define the Ethereum Network Upgrade Process. EEP-5 primarily covers Ethereum 1.0 upgrades. It suggested moving from ad-hoc hardforking to fixed-schedule and provides a general outline process with all required stages of hardforking. It was also pre-announced and requested for collaboration at Eth Magician then.

Based on the recent discussions in ECH meeting #8 and ECH meeting #9,a formal process of selection of EIPs for hardforks (Meta EIP#) is proposed #1929.

The ultimate goal is to have well defined process which every EIP author may follow in order to add EIP in next upgrade.

3 Likes

Absolutely love this, great proposal!

One suggestion I do have:
In 1929 it suggests to “Discuss it on gitter, reddit, and Twitter”. I would suggest the EthMagicians forum (mentioned in the prior sentence) be the source for discussions of an EIP, to prevent information dispersal through an endless variety of social channels. I would suggest to modify that sentence to the following:

“Inform others of the proposal via social channels, such as gitter, reddit, and twitter”
which implies that these are not “officially sanctioned” venues for discussion of EIPs (i.e. it’s not listed as discussions-to formally in the EIP).

That’s not to say it shouldn’t be discussed on other social platforms, but that any serious concerns brought up on such platforms may not be considered in the process unless the conversation is brought to the official forum outlined in the EIP through discussions-to.


This small language change I think would help to reinforce that the EIP has an official discussion forum to raise questions and concerns of the proposal, and to come to technical (and non-technical?) consensus on the proposal.

1 Like

Another potential edit I might have to this is that EthMagicians itself is not required to be the discussions-to forum, but that only one such forum should be specified for the discussion of a particular EIP.

An example of this might be that a proposal that is almost entirely non-technical in the concerns might find an alternate forum for discussions-to if EthMagicians is considered “inappropiate” by the author to host the discussions for some reason.

Thanks for feedback. I think it make sense to suggest EthMagician to be the discussion forum but author may decide it as per their preference.

1 Like

I’m not sure how I feel about using the EIPs repository to coordinate the contents of a hard fork; it risks confusing the EIP standardisation process with network governance, and the perception that EIP editors are the ones who decide what goes into a fork.

Other than that, this is a nice step forward in formalising forks.

4 Likes

Thanks for feedback. This is an initiative by Ethereum Cat Herders (ECH) to help out as HF coordinator, as discussed previously in All core dev call. So, if it is accepted by All core devs / EIP editors, we may make a slight change in this process of submission of EIPs. I hope it can also be managed at ECH GitHub. Would love to hear more about how does this sound?

I think this is great! I agree with @Arachnid and @fubuloubu’s suggestions, with the exception that the EIP author should be able to choose the venue for discussion as you mentioned in another comment. Having ECH helping manage this will help with organization of future hard forks.

2 Likes

Clarification: you agree or disagree that the author should have the option to specify the venue? Confusing sentence :sweat:

I still don’t understand how this differs from what the updated 233 outlines (PRs to hardfork meta) other than centralizing on CatHerders repo.

I’d rather see more updates to 233 rather than a separate Meta EIP.

1 Like

Whoops! It is confusing, my bad. The EIP author should be able to choose the venue.

1 Like

Good point. It may be better to iterate on 233. What do you think @poojaranjan. I can connect you with Alex (@axic) and others who are working on 233.

1 Like

Perhaps it is more useful to ask what purpose does ECH serve, and how they might fit within the process as the provider of some necessary service, and just keep that general (don’t specifically mention ECH).

I’ve thought about what it means to fulfill the PM role here, and really I think it ends up looking a lot like a political whip: querying different people on their opinions, building consensus, and understanding the political “lay of the land” in as non-partisian a way as possible.

EIP 1929 may be considered as a story of EIP 233 in Agile methodology; explained here.

To be brief, purpose, user and flexibility are the main reasons, I think they should be separate EIPs.

However, I will be happy to connect with Alex(@axec) and others who are working on 233 to further refine the HF process.

1 Like

I further think that EIP 1929 is process centric and not people/group centric. The purpose is to set up a process that may be followed with or without any individual /group.

1 Like

Does EIP 1929 make a proposal to change the current process? Or is it an attempt to document what the process is?

It is an attempt to document the process rather than changing the process. But in the process, it may also bring more clarity to new people who would want to contribute.

2 Likes

I think documenting the process is super, super helpful!

I also think that if there is no change proposed, an EIP isn’t necessary. I think that’s where a lot of the confusion is coming from with regards to this.

1 Like

I agree. I am not sure if we have any other way to document the process/improvement in Ethereum.

It’d be great to see this process documented somewhere, hence updated the proposal:

  • destination repository: ECH -> Eth1.0 spec
  • Tracker: ‘EIP readiness tracker’ -> ‘Network upgrade tracker’
  • added ‘Network upgrade stages’

PR available for review: https://github.com/ethereum/EIPs/pull/1929