Update EIP-1: Add numbering guidelines

[Pandapip1]

This obviously makes changes to the EIP numbering process.

[eth-bot]

✅ All reviewers have approved.

[Pandapip1]

Precedent: EIP-820 and EIP-1820

[Pandapip1]

Precedent: #5255, #5270

[Pandapip1]

Precedent: EIPIP meeting 85

[Pandapip1]

No precedent.

[Pandapip1]

Precedent: I previously allowed the bot to assign numbers on my behalf and everyone was okay with that.

[lightclient]

I feel like this is the only change that needs to be made.

[Pandapip1]

I think you forgot to include the change in your comment

[lightclient]

No I mean this line is the only thing from this PR that should be included haha

[Pandapip1]

It's hard to convey tone via text. Was this sarcasm or do you really think that this entire PR should be this one change?

[lightclient]

No tone, I mean exactly what I'm saying. I this this is the singular line of the PR we should merge. The rest does not need to be encoded as it is up to editor discretion.

[Pandapip1]

I mean there is nothing stopping you all from merging it.

I don't have an admin override. Only you and @SamWilsn have an admin override IIRC. @gcolvin doesn't even have write access to the repo.

Generally we've had an internal agreement than a single editor can veto a decision for a good reason and that seemed to be honored.

You use past tense, as if I have merged something past a veto. I do not believe I have. If I have, please let me know; I would be happy to revert it until all concerns are addressed.

I will, however, note that three editors vetoed your numbering of EIP-5000 but the number didn't change. I will, however, accept an argument that renumbering EIP-5000 isn't a veto, but is itself an action that you can (and did) veto. If this is your argument, I believe our disagreement is simply due a poor definitions of what constitutes a veto and what constitutes something that can be vetoed. Let me know if this is the case, it will make the debate easier for both of us!

Maybe you valued my contributions to the EIPs higher than the cost of letting a disagreement go.

The rules at the time of the numbering of EIP-5000 were clear, and you were compliant with them. You had the authority to number EIP-5000. It wasn't a question of values, it was a question of policy.

This statement also indicates that you are afraid that being an EIP editor has already become an adversarial game by your implication that I was comparing the values of you being an editor. I assure you that is not the case. I, like you, am concerned that becoming an EIP editor could in the future become adversarial, and I would like to proactively implement safeguards against that happening.

Maybe the editor group is simply unable to make any meaningful change.

I will remain optimistic that change can and will be made to avoid its negation becoming a self-fulfilling prophecy.

I don't want to go to a place where we play an adversarial game with the EIPs repo.

I agree wholeheartedly. Since there is division with regards to what the EIPs repository represents, I believe that clear, unambiguous, and fair procedures for all aspects of the process should be documented in EIP-1 to avoid any hypothetical adversarial games that could arise in the future. That is why I am making this PR: not to encourage the EIP process becoming adversarial, but to protect it against becoming adversarial.

I believe our viewpoints can be summarized as follows:

• @Pandapip1: Editors may have subjective opinions that affect how they act as an EIP editor. These subjective opinions may differ from one editor to another, and may come into conflict. To avoid this happening frequently, any time a conflict arises, the editors should debate and EIP-1 should be updated with new, less subjective rules.
• @lightclient: Editors may have subjective opinions that affect how they act as an EIP editor. These subjective opinions may differ from one editor to another, and may come into conflict. To ensure that the process remains simple, any time there is a dispute, it should be debated by all the EIP editors and a conclusion should be reached based on the unique circumstances of the dispute.

Would you say that is an accurate representation?

[lightclient]

You use past tense, as if I have merged something past a veto. I do not believe I have. If I have, please let me know; I would be happy to revert it until all concerns are addressed.

I'm saying that it was honored in the case of me vetoing the renumbering of EIP-5000, not that it wasn't honored.

I don't want to define veteo-able decisions. The world is too messy and we have too many other important things to work on then outline a fault tolerant governance process here. EIPs just aren't all that important in the grand scheme of Ethereum.

Would you say that is an accurate representation?

I think the part you are missing is that during disputes editors should be reasonable and respectful. Too often, these days that isn't the case. We are constantly in deadlock about different proposals; the other side unwilling to budge an inch. This isn't a healthy way to interact. ACD was able to coordinate one of largest software upgrades of all time with a single official rule. We should be able to keep track of some markdown files without a rule book too.

[Pandapip1]

I think the part you are missing is that during disputes editors should be reasonable and respectful. Too often, these days that isn't the case.

If I have disrespected you, I apologize. None of my comments or actions were meant to be disrespectful towards you, and I believe them all to be reasonable.

However, some of my statements have been intentionally designed to refute your arguments, which is a normal part of the debating. If these have come off as disrespectful, arrogant, or [insert any negative adjective here], I again apologize and request that you, in the moment, indicate what part of the phrasing you object to. In future, I will endeavor to avoid offending you. I however, will not apologize for making any of the logical arguments I have made.

We are constantly in deadlock about different proposals; the other side unwilling to budge an inch. This isn't a healthy way to interact.

I agree with this statement. That's what I intended to fix by asking you to confirm your position. We can now move towards a compromise.

Do you have any suggestion that we could implement to fix this in general?

ACD was able to coordinate one of largest software upgrades of all time with a single official rule. We should be able to keep track of some markdown files without a rule book too.

As I am not aware of the particular process that the ACD meetings used, would you mind telling me that rule and giving some anecdotal evidence of how the meetings were organized?

I hypothesize that the issue we are having with deadlock couldn't apply to them as they are dealing with completely objective material, with no wiggle room to debate values.

I don't want to define veteo-able decisions... we have too many other important things to work on [than to] outline a fault tolerant governance process here.

What is more important than determining what allows progress to be made?

EIPs just aren't all that important in the grand scheme of Ethereum.

I think you have acquired that perspective by being a Core dev. With that context, I would completely agree with you. However, ERCs and Interface EIPs are very important in the grand scheme of their respective parts of Ethereum. CC @SamWilsn

---

I'll stop debating for now and think about it. I can't think of any obvious compromise.

CC other editors @SamWilsn @gcolvin @axic

[lightclient]

If I have disrespected you, I apologize. None of my comments or actions were meant to be disrespectful towards you, and I believe them all to be reasonable.

This is a pretty cheap shot: #7396

As I am not aware of the particular process that the ACD meetings used, would you mind telling me that rule and giving some anecdotal evidence of how the meetings were organized?

I hypothesize that the issue we are having with deadlock couldn't apply to them as they are dealing with completely objective material, with no wiggle room to debate values.

We have a debate on what our priorities (values) are and try to determine the content of network upgrades based on that. There is no framework other than Tim facilitates the discussion and most people are have a similar shared context.

The editor group is very fragmented in terms of context and perspective. I personally find it exhausting to spend so much time dealing with the governance of this repository. I don't even get to edit as many EIPs anymore, because I spend all my EIP time having to argue with you and Victor.

What is more important than determining what allows progress to be made?

Shipping EIP-4844. Figuring out single slot finality, or at least how to reduce the attestation aggregation load on the network. Making sure mev-boost is safe. Finding the cause for the increased ommer rate on the beacon chain. Finally shipping verkle and making stateless full nodes a reality.

Do you understand how silly it is that the 4 active editors go around in circles for months and months about how to number EIPs while there are actual legitimate problems that we could be turning our attention to?

ERCs and Interface EIPs are very important in the grand scheme of their respective parts of Ethereum

not everyone wants to get wrapped up in the bureaucratic nightmare that is getting an EIP over the finish line --@transmissions11

What is the last truly important ERC? Maybe permit? Probably 4337? The market is going to find a solution to ERCs if they don't serve their users. I can definitely say we spend an inordinate amount of time debating these processes than there are downstream effects.

[Pandapip1]

This is a pretty cheap shot: #7396

It was intended to provide a concrete example of why I felt there needed to be a change, and to accelerate my understanding of your point of view. In both regards, it was successful. It was by no means meant to offend you.

The editor group is very fragmented in terms of context and perspective. I personally find it exhausting to spend so much time dealing with the governance of this repository. I don't even get to edit as many EIPs anymore, because I spend all my EIP time having to argue with you and Victor.

I happen to agree with all the points here. The editor group is fragmented in terms of of context and perspective. It is somewhat exhausting to deal with the governance. And I'm not reviewing as many EIPs due to debating governance.

I am open to suggestions to make this process smoother. If we switched to a majority rules, then governance would go smoother, at the cost of being less stable. I would understand if that's a tradeoff you would not like to make, and I will not be pushing that idea. Again though-if you have any ideas to speed up governance, I'm all ears!

Shipping EIP-4844. Figuring out single slot finality, or at least how to reduce the attestation aggregation load on the network. Making sure mev-boost is safe. Finding the cause for the increased ommer rate on the beacon chain. Finally shipping verkle and making stateless full nodes a reality.

Do you understand how silly it is that the 4 active editors go around in circles for months and months about how to number EIPs while there are actual legitimate problems that we could be turning our attention to?

If you feel that the former are more important questions than the latter, then why are you choosing to spend your time on the latter? Serious question. I am not trying to make fun of you. I want to know your thought process here, since I can't follow it and we're not going to find a compromise if I can't understand why you have the position you have.

What is the last truly important ERC? Maybe permit? Probably 4337? The market is going to find a solution to ERCs if they don't serve their users. I can definitely say we spend an inordinate amount of time debating these processes than there are downstream effects.

This is a fair point, and ties back in to what was mentioned two paragraphs ago in terms of speeding up governance. If you have any ideas, please, please, please let us know!

[SamWilsn]

There's a lot of discussion on this PR. Hopefully I didn't miss too much there 🤣

My thoughts are that we should go with something like @abcoathup's suggestion. Perhaps:

- Assign an EIP number (in a method determined by the editors, generally incrementally.) Attempting to get a specific number, also known as number sniping, is discouraged.

I don't think we want to formalize more than editor discretion.

[Pandapip1]

I don't think we want to formalize more than editor discretion.

Fair enough. I am okay with that as long as we aren't loosening the rules.

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...