I made this proposal years ago and people got mad at me.
3 Likes
I agree with @kdenhartog that the IETF structure is probably the way to go. I think we should get rid of the standard track type, and replace it with “core” and “ERC” (yes, this turns interface and networking EIPs into ERCs).Then, I propose we replace “category” with “categories”. Final EIPs can have categories added to them, and if authors from >5 Final EIPs come together, they can create a new category and add it to those EIPs, ensuring that the list of categories is up to date. The categories that will be displayed on the nav bar will be the five categories that maximize the number of EIPs discoverable.
1 Like
You are not alone. I definitely resonate a lot of frustration with you and EL/CL devs.
QQ: when you tried to get more editors for EL/CL, what has blocked your candidate from being admitted as editors?
How about this: admit everyone / a few members of EL/CL spec who currently has merge power of that repo as new Core EIP Editors and let them merge Core EIP PRs? @timbeiko
Thanks for writing up this proposal @timbeiko!
This is one of the longest debated topics among editors. In the very early days (circa 2017), we thought that EIPs and ERCs could coexist in the same repository and be driven by various “rings” (e.g. working groups of magicians). Interest in rings dried up and we went several years without much coordinated work on EIPs outside core.
In mid-2020, I proposed to revive the concept and more closely follow the IETF organization structure by having working groups tackle specific topics / domains, each equipped with a champion who would be able to hold the group accountable and ensure progress (something I felt that was missing from the early rings).
Unfortunately this still did not gain traction. It eventually led to more serious discussions about bumping ERCs out of the repository entirely, to allow application developers more opportunity to self-organize. Because EIPs are critical to the core Ethereum protocol, we have generally been hesitant to grant individuals editorship who are not actively engaged with the protocol and strongly aligned with the philosophical interests of Ethereum.
And so, although many app devs are extremely talented and have great application-layer vision, it often felt inappropriate to include them as EIP editors because of the sensitivity of the position relative to Ethereum’s governance process. Plus, there simply were not many candidates who seriously pursued editorship in the first place.
In the intervening years, the EIP process has changed substantially. In some ways we are much better off than before. The work by @SamWilsn and @Pandapip1 on improving the CI infrastructure has led to much more consistency across EIPs, and generally the review quality is rather strong. In other ways, we have created a system that developers want to avoid at all costs due to arduous requirements, nitpicking, and poor communication about expectations.
–
This is the long winded way of saying that EIPs are at a local (I hope) minimum of relevance. There are a lot of issues and we can’t fix them all at once. I think that splitting the repositories down the line of “app standards in this repo, core in this one” is the best first step. We should focus on the one EIP type that we are good at, core EIPs. They’re also arguably the most important type. Applications can and will create standards outside the EIP process. I think it is paramount that we eventually work with them to develop open standards with the community, but it is something we have been failing to do for over 6 years now.
IMO it’s easy to think that this change will drastically affect the community, but the reality is that they don’t care and are extremely amenable to change. I am really impressed with how quickly we were able to change many processes / naming schems that felt deeply embedded into the core of Ethereum: eth2 → EL+CL, ERC → EIPs → and now back again, ACD → ACED (okay I’m still not sold on this one, sorry Tim), etc.
It will certainly be an inconvenience in the beginning, but I believe we will come out the other side with a better scoped organizational structure to begin engaging more contributors who do care about the ecosystem and its core processes.
3 Likes
Thank you @gcolvin @kdenhartog @fulldecent @Pandapip1 @xinbenlv @matt for sharing your perspectives - I appreciate the engagement here!
I think it’s worth it for me to take a step back and explain “where this is coming from”. The #1 thing that “keeps me up at night” here is that, today, we don’t have a single, unified, way to specify a change to the Ethereum protocol. I understand the historical reasons why this is the case, and think we generally made the right decisions to get us where we are. That said, in a post-Merge world, I feel like the specifications, and their associated processes, for Ethereum should also be “merged” (although I can live with minor differences, especially early on).
As many have noted in this thread, we’ve been circling this problem for a long time. My concern today is that the EIP process is very hard for some of Ethereum’s most important contributors - consensus-layer devs & researchers - to approach and engage with. After talking with several of them about this, my general impression is they feel the EIP process is high friction, not particularly well-suited to how they work and, most importantly, reluctant to change to accommodate them.
My rationale for splitting out ERC & EIPs is that this can be a first step to create a process for core protocol changes that works for both the execution and consensus layers. I feel pretty strongly this use the “EIP brand”, as it has very broad community recognition (see, e.g. EIP-4844 now, or EIP-1559. previously). Similarly, I think ERCs have achieved escape velocity as application standards (i.e. other chains even use $TOKEN-20/721 as their token standard, mimicking ERC-20 or ERC-721).
I appreciate there might be some technical overhead to splitting the actual repos and my goal isn’t to create needless work for anyone, but I do feel that integrating the consensus layer as part of the EIP process is critical to do relatively quickly, and we should be fine taking steps that aren’t as “clean” to make that happen. Given that, I’m skeptical that a short term solution here is “adding another layer of process” rather than “loosening some of our constraints to attract these people and iterate on a process from there”.
Another idea I’ve half-jokingly proposed is to myself become an EIP editor with the sole purpose of making life easier for CL folks who want to contribute 
Hopefully this context helps! I’ll be on the EIPIP call this week to discuss this further, too 
Now, here are a few more specific thoughts on the replies 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.
I don’t have any issues with this, assuming we can then have more flexibility in updating the Core EIP processs. That’s the main thing I’m after with this proposal.
I do think that Core protocol changes will need a different process from application-layer standards. We already see this in EIP-1, which has a whole section on how Core EIPs are different.
I actually feel the exact opposite here: today, CL changes don’t even have EIPs. The number of eyeballs looking at the PR-by-PR changes to the consensus-specs is much lower than the number of eyeballs who can track EIPs X, Y, Z. I strongly agree with you that we should have a process which highlights changes to Ethereum, and that’s why I think we should be willing to “bend” most/all of our other standards for the purpose of having CL changes included in the EIP process.
That’s not the problem, though: the problem is CL EIPs don’t exist today.
While I agree at a high level, I do think there are some pretty important technical distinctions between application standards (opt-in) and core protocol changes (applied to all the network at a specific time). We already have separate specs for APIs, and I think that’s been a good thing. IMO specialization at the spec level doesn’t mean the community fragments, but instead that we can better support its different growing niches.
The main blocker is people who have the skills don’t have the desire to do this. I’m somewhat optimistic that if the EIP process was more accommodating to CL folks, we could get a couple of them to eventually join as (Core?) EIP editors.
I’m happy with that if we’re okay with them not explicitly following all existing rules. If it lowers frictions and helps us build a better process, sure!
*ACDE
2 Likes
Cross referencing this post because I think it’s highly relevant to this discussion as well:
One thing that’s clear to many of us here is that we need to find a process to move forward still and from the sounds of @matt we’ve actually tried to land one something similar to what I’ve proposed. As dumb as this sounds, I think part of the issue of why this might not have worked in the past is simply in how we’re using github, FEM, Discord, and Twitter to organize discussions and move work forward. As I’ve heard it put best “We shape our tools and then our tools shape us”. In this case, I think because we’ve tried to keep the “EIP process” within a single repository inside github that’s forced a lot of the processes we have today. For example, discussions moved to FEM because it was too hard to find the relevant discussions in the GH issues (I assume - please correct me if I’m wrong @matt). Also, editors ended up being core to the process because they were the ones who had merge rights in the repo. So, I think as we look at these changes we need to also evaluate how we’re using the tools to make this work.
For this reason, I don’t think my proposal in that linked post is best to do this in one large sweeping change. Instead my hope is that it is a “guiding plan” that we can iteratively implement and improve (or ignore in some cases) as we come across problems we need to solve.
For this specific problem (and I think it rings true for core devs and wallet devs alike) I think the first simplest step forward that we take is to form GH orgs for “ethereum-core” and “ethereum-standard-contracts” where we can start to create repos for EIPs to move forward. We could then turn the EIP repo in the “Ethereum” org into a landing page of sorts for finalized EIPs and a way to redirect to the other EIP areas. This way we’re still all within the “EIP brand”, but we’ve also got a bit more space to specialize and cultivate independent communities which we can cross pollinate in due time.
Also, I intentionally didn’t mention “ethereum-wallets” because I’m hesitant what to propose for wallets right now. Many are going multichain (not just EVM based, but also Solana or UTXO) these days so keeping this work only under the Ethereum umbrella could actually harm this area of development. We can figure out what to do for wallets a bit later, but it would be good to see what people think for them specifically once we’ve worked through getting the core/CL community and ERC community sorted first and learned what works and what hasn’t.
Discussions are on FEM because we try to minimize dependence on GitHub itself, and to aggregate discussion for each EIP into a single persistent thread instead of over multiple PRs and issues.
1 Like
How does removing something that is not even relevant to CL teams help them feel more comfortable in contributing to the EIP process?
Its Not the EIP process that is bureaucratic, its ACD. There its been said.
Adding a even odd numbering system makes things even less coherent.
If wanting to make such processes more accessible, maybe adding a “fast lane” shepherding process to expedite things would be beneficial. Give each CL team one such indulgence per quarter so that they can use it for things they want to prioritize getting through.
Thanks @timbeiko for triggering this serious and important discussion and taking time to patiently respond to me. Sorry I have been quite busy recently and thus delayed to put down my responses in detail.
That’s a good compromise to me. Having two sets of EIP editors and if necessary two editing/merging rules sounds much less controversial and better backward compatible than “forking the ERC out of EIP”. If you wanna make it an alternative proposal, I will co-sign the petition with you, including allow the Core EIP has its own editing rules ignoring all other existing rules. I am also happy to see the ERC EIP Editors / workgroup form from a group of people who specialize in smart contract and application building too.
If you don’t have time to draft this alternative proposal, I am happy to draft it too. Let me know how you like to do it. @timbeiko
Yeah. I feel sad that is the case and this is huge room of improvement for us as a community. We need to be able to attract contributors. I am in favor of making the EIP process more accommodating to “adopters”: CL/EL client devs of course, and also dApp developers, each in their working group.
Your complaint is not controversial - I agree with you a lot.
You probably use “EIP Governance” to mean the “restriction before merging”. In that, I totally agree that it’s too much restriction.
When I use the “lack governance”, I mean something different. I will address this in a separate response.
Wearing my developer hat I understand the execution-spec and the like are better than YP. Wearing my PhD student hat, I however understand the academia needs something like YP, just like @gcolvin mentioned. The problem with YP lack of updates is not inheriting to YP itself, it’s a living testimony of that we haven’t foster a good enough open contributor culture to YP and a room of improvement. We can discuss this later.
It’s not in the scope of the EIPs repo to care about which EIPs are implemented where. IMO a core EIP that doesn’t get included should still be finalized in the EIPs repository, assuming it was extensively tested.
The process need not be different for Core EIPs and ERCs. Core EIP authors want their spec to be included as fast as possible in order to maximize visibility, to get discussion started, and to allow suggestions and proposal forks to be made. The same motivation is true for ERC authors. Therefore, the idea of splitting the repository makes absolutely no sense.
Apologies for my likely superficial perspective here, but I just caught this issue by chance.
However, I can’t help but wonder are the EIP volunteers or paid? (Will follow up depending on answer).
Mostly volunteers, though “it depends”. Ethereum Cat Herders offered some stipends to some (and still might?), others do this as part of their “day job”, etc.
1 Like
Random twitter poll points to community being okay with splitting them up: https://twitter.com/lightclients/status/1623372648783953920?s=20&t=fqctjq_WIOreSee7JPNNdA
2 Likes
I am very pro splitting EIPs and ERCs. I don’t have the capacity to read the whole thread but I wanted to respond to a few points.
I think the biggest advantage is focus. Right now I never look at the EIPS, only if I am forced to (when I have to implement something, …). I never have the urge to go and lock what cool new EIPs are currently being drafted, because there are 92 open PRs, most of them concerning ERCs.
I disagree with this. In my opinion splitting the processes will actually increase the number of eyeballs on the EIPs. Right now no one looks at them (except the EIP editors) and as I said earlier this is because of so much spam and unnecessary or useless proposals.
The intentions and goals might be the same, but the audiences are very different. EIPs are meant to be discussed and reviewed by core devs, while ERCs are used by the greater community to establish standards. They require different processes and have completely different audiences imo.
I think EIPs are a tool and as a tool they should serve the core dev community. They are not doing a great job at that (I think everyone can agree on that). Splitting the repos into two will be a great step in the right direction imo. It will allow us to focus while giving the greater community a shelling point for their proposed standards as ERCs. Historically having the same process for both might’ve made sense when we had 20 proposals, but with >4000 proposals its just not practical anymore.
I also like some of the other proposals, like creating an RSS feed and mailing list, but they should be secondary to us splitting the repos.
2 Likes
Since it’s a role that does not have the same prestige as a client developer (broadly speaking) I think it is more like a job than a volunteer role The struggle to get volunteers speaks to this. I think like the website there should be a few people who are paid to do EIPs, funded by the EF. Just my 2c.
Okay, here is the solution to everyone’s issues:
And a full narrated YouTube explaining it: New EIPs homepage PR 6483 - YouTube
Don’t have time to click that button? Here is a gif, you’re already watching it…
3 Likes
The biggest reason to split the repositories is that it will make it easier for the processes to diverge, both in governance and technical stuff (like CI.) Sure, we can have the processes diverge in the same repository, but it makes the tooling simpler if we also split the repositories.
1 Like
Our bots do add tags to the PRs to make them easier to search (eg. Core Only) but I do very much see your point here.
2 Likes
FYI - you can filter PRs easily. For example, to view only new Core EIPs, you can use:
https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ac-new+label%3At-core
EDIT: Wow, I missed sam’s comment above. Great minds think alike, I guess.
1 Like
A meta-comment on these recurring split-the-repo discussions:
My old psychology mentor had a (tautological) maxim: “If a situation calls for a person to do something they can’t do then they will do something they can do, if they do anything at all.”
It seems to me that we have social problems that we don’t know how to solve, so we are trying to solve technical problems instead.
3 Likes