I hate to wade into this, as we’ve been having this conversation for years and have yet to fork – I fear we will just rehash the same old arguments, on top of new arguments So, wishing to only get my toes damp, (but knowing that my whole body will likely be getting wet) and repeating some points already made above and elsewhere by myself and others …
First an observation – our process was initially modeled to a large extent on the IETF process. They have been managing the evolution and specification of the entire Internet for many years now within a single editorial process. I don’t see that our project is at anything close to that scale.
We should fork the EIP repo to create an ERC-only one, with ERCs displayed at
ercs.ethereum.org
I don’t think simply forking the repos will solve the problems you bring up, @timbeiko – most of which I agree are problems – and will cause more problems as well, as noted by others above.
I think some of the problems a fork per se might solve could also be solved within the repo by things like enforcing EIP vs ERC naming conventions, having separate ethereum/EIPs/EIP and ethereum/EIPs/ERC directories, adapting our requirements and templates to different needs, and other such.
The processes can evolve independently, to suit the need of EIP vs. ERC authors, and welcome CL contributors to EIPs
I don’t think our users needs are so disparate we need separately evolving processes – I think that will just get us an even more confusing set of processes which would only get worse over time.
To avoid name collisions, EIPs get even numbers, and ERCs get odd ones.
We’ve already lost an editor to disagreements over numbering.
EL & CL teams currently have very different approaches to specifications, and it is to be expected that how EIPs are used in the context of network upgrades may change to accomodate CL practices, leading to further divergence between EIPs (especially Core EIPs) and ERCs.
Again, I don’t think the changes should be so great as to require separate repos. I think that would only complicate matters. Better to work on harmonizing the approaches. These are layers of Ethereum, not entirely separate protocols. For the most part the same client teams are working on both layers.
Finally, the concept of “ERC editors” has come up frequently, and been stated as a “blocker” to separting out EIPs from ERCs. That said, ERCs do get reviewed today. By forking the repository, EIP editors would automatically be ERC editors as well (and free to resign from this). If this leads to no ERC editors, then it will be a strong signal to the community to step up and invest in this.
I think the signal is already pretty loud, and having diverging teams will only make things worse.
I’ve suggested before, as I think @anett has, that we need to lean more heavily on the Magicians. ERCs cover a much wider range of interest and expertise than EIPs so it’s not a surprise that not many people are interested or qualified to review them all. IETF proposals are vetted by established working groups before they get to Draft stage. Rings of Magicians were intended to do the same, but haven’t really taken off. But one way or another I think we need to encourage and support peer review to take a load off the more more permanent editorial staff.
It’s important to remember that while there are constraints EIP editors can impose, the goal of the EIP and ERC processes should be to serve authors. If EIP and ERC authors have different goals with their specifications, the processes should accomodate them differently.
I totally agree on the goal. But for all the reasons above and more I don’t think having multiple diverging processes and teams of people is the way to go.
So how do we get a better consensus on what the needs are and how best to serve them?