It would be a little easier if we had a list of champions somewhere. Perhaps a list that doesn’t require the author’s permission to edit. (i.e. not a new field in the submitted EIP) I could then pull that list into the spreadsheet as well. A meta EIP like 1679, but for tracking Champions/Shepards.
I could also look at pulling information from the wiki into the spreadsheet. It feels a bit like a meta-EIP may be better than the wiki, but I would want to think about it more. What are your thoughts here @boris ?
I’m confused. The list of champions is the authors of the EIPs. If none of them actually champion it, then there’s no point having it listed.
I don’t see how can a champion be separate from an author, because championing it through the process likely requires a lot of updates (clarifications) made to the EIP draft.
But, You can have an EIP with Authors but no active champion
If the only list is in the EIP itself, then only the authors can update this information. Which if it is inactive, then the authors aren’t even there to update it. That is a catch-22. Having a separate list somewhere of who is the current champion means other editors are able to update this information.
If it is updated in error it will be pretty simple to bump someone to be the active champion again which is also a good signal of the EIPs real activity.
Perhaps there is a better way of handling this, but leaving it up to the authors to self-report inactivity seems a bit fruitless.
That is actually not true, the EIP Editors can extend that (at least it happened in the past), especially for those EIPs which have an open source license (all of them do, with the exception of this list).
The “champion” needs to submit a PR adding themselves to the draft and editors can merge that.
There would still need to be added an “active champion” field somewhere on the EIP for editors to update this information. Currently, looking at an EIP I have no way of knowing
If there is an active author (Is the EIP active?)
Who is the active author (Who is the Current Champion?)
For some background. I am running into these problems since I signed up to help Dimitry with testing coordination. I made the spreadsheet so I can track the progress of testing among EIPs and I am also compiling a list of Point of Contacts (Active-Champion) so I can update the progress of testing. It didn’t make sense to keep this information to myself as I am already going to need to maintain it and would rather share it. Also, I don’t want to be an EIP editor, so some way to maintain and share the lists without becoming an EIP-Editor would be preferable.
I would love to see this go through.
I have 20 hours a week I can spend and I want those to be where they are most helpful. I would appreciate some guidance as it is really difficult to get a sense what helps verses what adds work for others in a permissionless leaderless group. So instead I have been bumbling around trying my best to do what I see. Maybe it would be good to have a call @axic?
Can you please explain why should it be possible that there’s no technical person as a point of contact for a protocol changing Core EIP? I can understand that could be the case for ERCs or non-Core EIPs.
Core EIPs should be serious specifications and there should be an obvious way to reach someone capable of answering specific technical questions about a specification. If there are multiple hops someone has to go through to reach a technical person, then I do not think such a Core EIPs should have a chance to be accepted. If there is no technical person willing to champion it, that signals to me there is no technical need for it.
At the specification stage (e.g. Draft mode) there must be a technical champion. When the specification is clear and coordination focuses around implementing the change in second and subsequent clients, there I could see non-technical coordinators to play a big role.
Yes technical people need to be involved. To pick on @MadeofTin, he’s not going to be able to defend a Blake2b precompile. But he could coordinate whatever is happening in the GitHub / Gitcoin thread.
EIPs with multiple authors needs to have one POC, a team (eg Parity or a Working Group) having a single point of contact for multiple EIPs, etc
This is all theoretical so let’s just do the work of filling out the spreadsheet. I’d like to capture the name not just GitHub handle.
@MadeofTin there are lots of things we can’t see by looking at an EIP, which is why we’re going to need to track things outside of a Markdown file
Accepted as a Draft? Maybe the EIP-1 requirements need to be updated because that wasn’t on the list when I submitted blake2b nor 2025.
Your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.
As far as I can tell, that is exactly what I am doing. Of course, anything beyond being accepted as a Draft I understand. Why “accepted as draft” is the gatekeeper for this I don’t understand. I will respect it, I just don’t understand it.
What is the issue in labeling an EIP as Draft? Being draft doesn’t mean you are going to be accepted. Being draft doesn’t mean the core-devs need to bring it up on calls. After it is accepted by an editor it could never be brought up again. It is the first stage in the rest of the process. My previous understanding was that the requirements to be made a draft is that it was correctly formatted.
Draft – If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP.
Draft – Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backward compatibility, or not in keeping with the Ethereum philosophy.
Draft – Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
What is the resistance to marking things as Draft? I am not upset, I just want to understand where I am wrong on this.
This is our first time through the EIP driven network upgrade process, so I don’t think any of these rules are hard and fast but are taken more of a measure of what EIPs are viable for this specific network upgrade. The fact there is a document that can be pointed to and a person willing to attend calls and advocate on FEM I think are the two strongest indicators, aside from the next checkpoint which is actual implementation in clients.
I know the deadline have passed but I would like to add a last minute proposal (EIP-2075) since it relates to 2 proposals already part of 1679 (EIP-1706 and EIP-1930).
EIP-1 currently requires a “technically sound” specification.
Also from EIP-1:
The main point of being Draft and having a somewhat comprehensible Specification is to allow actually useful discussions to happen around it. If a Draft doesn’t have any specification, then how will it be discussed?
It solves the problem for me
Draft – If agreeable, EIP editor will assign the EIP a number (generally the issue or PR number related to the EIP) and merge your pull request. The EIP editor will not unreasonably deny an EIP.
Draft – Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backward compatibility, or not in keeping with the