Separating EIPs and ERCs

As this was just briefly topic at the end of the AllCoreDevs meeting just now (and the idea there was also to bring it up here) - I am opening this discussion with this post. I am still a very big fan of this idea. Started an initiative for this a while ago:

People liked it (just some bike-shedding around the naming) - but I am not sure about how to roll this change out - this was also the reason I did not proceed with it. If anyone has an idea how to actually roll this out: please shoot!


Run both in the EIPs repo. But have more clearly defined separate tracks. Have ERC editors separate from EIP editors (although both have power to help each other out with the basics).

I have an edit in progress to track and bring in more specifications — JSON-RPC, devp2p, whisper. So that everything to build a compliant and compatible Ethereum client is in one place.

I’m up for discussing and helping with this.

1 Like

I think they should not reside in the same space. Really separating them has some advantages - e.g. something trivial like smaller numbers that are easier to remember :slight_smile: - also I think it makes the process more agile as one group can move/change processes without influencing the other one.

1 Like

So, separate repos for each type of specs? I’m not super tied to one approach or the other, but i believe that there aren’t enough people involved in the process today, and splitting it means there will be even less.

And that coordinating in general will be harder.

Do you have some specific thoughts of how this would work? How do we brainstorm approaches?

More broadly — who cares enough to help?

1 Like

Ya - splitting it in very fine granularity would not be good. I would just split in 2 parts (for now) - EIPs and contract interfaces. In the EIPs we could still go track route you suggested. But I think contract interfaces should be really split out already.