Call for Input: Update Final ERC-7540

SamWilsn commented 1 month ago

Call for Input

Decision	Do we merge https://github.com/ethereum/ERCs/pull/670 ?
If Affirmed	https://github.com/ethereum/ERCs/pull/670 is merged
If Rejected	No change
Method	Rough Consensus
Deadline	November 15, 2024

Background

Changing some event names in the text to match the YAML description.

Checklist

I, the opener of this Call for Input, have completed the following:

[x] Filled in a descriptive title.
[x] Filled in the "Decision" field.
[x] Filled in the "If Affirmed" field.
[x] Filled in the "If Rejected" field.
[x] Filled in the "Method" field.
[x] Filled in the "Deadline" field to be thirty days from creation.
[x] Added any relevant background information (or removed the section.)
[x] Published a notice in writing to the usual channels frequented by EIP Editors (likely Discord.)
[x] Commented on this Call for Input, clearly stating my opinion (or abstention.)

SamWilsn commented 1 month ago

In Favour

abcoathup commented 1 month ago

I'm against unless a majority of authors approve the change.

EIP editors shouldn't be choosing here. UPDATE: A majority of authors have approved ~It should be the majority of authors, so far it is 2 out of 6, they need two more to approve.~

SamWilsn commented 1 month ago

Before a proposal is final, we only require a single author's approval for changes. I don't see why we need to make it a majority after. The process for changing a final proposal could be:

Is this clearly a mistake?
Does the proposed change fix the mistake?
Is the proposed change the smallest correction possible?

Author approval helps with (1) and (2) but I don't even think it's strictly required (though I'm a lot more comfortable with it than without.)

abcoathup commented 4 weeks ago

Before a proposal is final, we only require a single author's approval for changes. I don't see why we need to make it a majority after.

A non-final standard is expected to have some changes, though ideally these are smaller as it gets closer to final.

A final standard isn't expected to have any changes. Users should be able to build/implement using the standard safely without the concern that it will change underneath them. We don't have version numbers, so any non-trivial change should really be a new EIP/RIP/ERC.

If changes to final standards are allowed (and I am generally against this), the bar to make a change should be really high.
The responsibility shouldn't be on editors to decide if a change is correct. This should be on the authors. Hence we should require a majority of authors to approve any change to a standard.

1 & 2 should be the decisions of the majority of authors. Editors shouldn't have this responsibility. 3 is where editors can help guide, but ultimately it is on the authors.

In this specific case two events have been renamed and a parameter added to a method. This is something that authors should approve/not approve.

hieronx commented 2 weeks ago

@SamWilsn @abcoathup the PR has now been approved by 4/6 authors: https://github.com/ethereum/ERCs/pull/670 Working on reaching out to the other two as well but hopefully this suffices already!

abcoathup commented 2 weeks ago

@hieronx glad you now have a majority of authors approving with 4/6. I am against any changes to final ERCs but wouldn't oppose one which is approved by the majority of authors.

If the change is allowed by editors I recommend adding an Update Log to the Eth Magicians discussions topic. (See: https://ethereum-magicians.org/t/template-for-discussion-to-threads/20347) So that you can clearly communicate with ERC users when/why this change was made.

hieronx commented 2 weeks ago

We are at 5/6 approvals now.

If the change is allowed by editors I recommend adding an Update Log to the Eth Magicians discussions topic. (See: https://ethereum-magicians.org/t/template-for-discussion-to-threads/20347) So that you can clearly communicate with ERC users when/why this change was made.

Good idea, we'll do that!

ethcatherders / EIPIP