Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update EIP-1: Add numbering guidelines #7388

Merged
merged 5 commits into from
Aug 27, 2023
Merged

Update EIP-1: Add numbering guidelines #7388

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
6fd09ee
Update EIP-1: Add numbering guidelines
Pandapip1 Jul 24, 2023
d46b890
Switch from * to -
Pandapip1 Jul 24, 2023
637573f
Update to new wording
Pandapip1 Jul 30, 2023
f61ce8e
Remove other stuff
Pandapip1 Jul 30, 2023
4ad706b
Update EIPS/eip-1.md
Pandapip1 Jul 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions EIPS/eip-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,7 +118,7 @@ EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wik

Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.

`eip`: *EIP number* (this is determined by the EIP editor)
`eip`: *EIP number*

`title`: *The EIP title is a few words, not a complete sentence*

Expand Down Expand Up @@ -146,6 +146,17 @@ Headers that permit lists must separate elements with commas.

Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).

### `eip` header

There are a few paths to receiving an EIP number:

- The bot may automatically assign a temporary mnemonic while the EIP is still a PR. Before the PR is merged, an EIP number may be assigned by the bot.
Copy link
Member Author

@Pandapip1 Pandapip1 Jul 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- EIP editors can manually assign EIP numbers sequentially.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Precedent: EIPIP meeting 85

- With the approval of half of all governing EIP editors (rounded up), any EIP number can be assigned.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No precedent.

- If the EIP fixes an existing Final EIP, only one EIP editor (governing or non-governing) is needed to assign an EIP number.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Precedent: EIP-820 and EIP-1820


If more than one EIP number is assigned, authors may pick any assigned EIP number. If the EIP number assignment is subsequently retracted by any governing EIP editor or the editor that assigned the number, the EIP may not use that number anymore. The only remaining EIP number cannot be retracted; a new one must be assigned first.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Precedent: #5255, #5270

Pandapip1 marked this conversation as resolved.
Show resolved Hide resolved

Pandapip1 marked this conversation as resolved.
Show resolved Hide resolved
### `author` header

The `author` header lists the names, email addresses or usernames of the authors/owners of the EIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the `author` header value must be:
Expand Down Expand Up @@ -451,7 +462,7 @@ If the EIP isn't ready, the editor will send it back to the author for revision,

Once the EIP is ready for the repository, the EIP editor will:

- Assign an EIP number (generally the PR number, but the decision is with the editors)
- Assign an EIP number
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@Pandapip1 Pandapip1 Jul 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you forgot to include the change in your comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

@lightclient lightclient Jul 25, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@Pandapip1 Pandapip1 Jul 25, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Pandapip1 marked this conversation as resolved.
Show resolved Hide resolved
- Merge the corresponding [pull request](https://github.com/ethereum/EIPs/pulls)
- Send a message back to the EIP author with the next step.

Expand Down
Loading