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
Come to a decision.
Fork it!
1 Like
I think you brought this up in the last EIPIP meeting, @Pandapip1. For core EIPs the original concept of Final really was running on the mainnet. Up until then the specification must be open to change – otherwise what is deployed might intentionally not match the Final spec.
Just because that was the original thought doesn’t mean that the process can’t change to support a competing idea, especially if circumstances have changed. The Ethereum mainnet is weakly subjective now, and we have stated as a goal that we want to remove as many subjective traces as possible from the EIP process!
I guess it doesn’t matter that much when we call it Final, because it rarely happens that the behavior of what is deployed is different than specified. If it is, then that can be handled with an Errata
I am 100% for splitting the repository, on the condition that the ERC repo can facilitate external links or require some code to be included i. The proposals.
The main issue with ERCs – there is not a formal way to describe the interface for contracts. Have a standard repo –– this will lead to a canonical ABI definition –– can have semantic rules around this. Can run some specific unit tests against this, etc.
Some clear principles or rules governing what basic terms/definitions are for included code, eg:
(this is an example, not an accurate representation/definition!)
Abstract ABI: a generated contract ABI interface; as described in the ABI generated artifact; is called an ABI definition. Each ABI definition has an associated ABI identifier; e.g. constant, inputs, outputs, stateMutability, payable, type, name (which may be implicit in the case of Contract).
Instead of “Final” how about: conclusive? Additionally a state that can communicate that this relevant EIP/ERC is no longer valid/useful or has been replaced would be “Moribund”
After years of these discussions, I remain 100% opposed to splitting the repos..
Fwiw I think splitting the repos would have the w benefit of making package management for smart contracts more viable. If the ERC repo has some constraints, it could be much more easily adopted by developers seeing that its being supported.
1 Like