EIPs

EIPs copied to clipboard

Knowing when an EIP became final is often useful as it gives an idea of how long the standard has been in place. For example, I wanted to know when CREATE2 was added to Ethereum approximately, but eips.ethereum.org doesn't have that information currently.

Is it a good idea to add it as a preambble field?

Preamble makes sense to me.

Definitely seems like something that should be automated.

Any objection to add a “finalized date?” If no one has concern, I can send a pull request to add a field to preamble and EIP-1.md (but not bot)

No objection from me. I would love that!

Definitely seems like something that should be automated.

I've sent out the Pull Request. It's manual for now. I wonder what's your thought on automating it

IMO finalized is a trailing indicator of something else that is much more useful: what hard fork the EIP was included in. I think rather than finalized-date, the tag should be network-upgrade or something similar.

sorry deleted spam and comments responding to it.

"Network upgrade" reads to me a bit unclear what it refer to. If you are referring about Core track, wouldnt there be a "FORK_BLKNUM" already in the content of EIP? If my understanding is incorrect could you ellaborate what you refer to?

I would love to have an indication in the EIP of what fork implemented it.

That said, I think there was some historical context for why we don't include that information?

That said, I think there was some historical context for why we don't include that information?

Because Micah thought the EIP process should be purely a standardization process and disconnected from governance type decision making. Now that you got rid of that guy, you could do something different.

IMO finalized is a trailing indicator of something else that is much more useful: what hard fork the EIP was included in. I think rather than finalized-date, the tag should be network-upgrade or something similar.

In theory, Core EIPs should become final as of the hard fork they are included in, so this should functionally be the same.

Now that you got rid of that guy, you could do something different.

No, you got rid of that guy.

In theory, Core EIPs should become final as of the hard fork they are included in, so this should functionally be the same.

I could have sworn that there was some format of EIP for forks and that each fork got its own Meta-EIP. I could be wrong.

@Pandapip1 we used to have meta-fork EIPs, but switched over to using the execution specs.

In theory, Core EIPs should become final as of the hard fork they are included in, so this should functionally be the same.

Again, this is a trailing indicator and requires humans move things at certain times for consistency. We should remove that dependency and simply include the the upgrade the EIP is activated.

That said, I think there was some historical context for why we don't include that information?

Because Micah thought the EIP process should be purely a standardization process and disconnected from governance type decision making. Now that you got rid of that guy, you could do something different.

As much I respect the expertise and many values you bring to us @MicahZoltu ,joke aside, I'd say that "governance" for me is defined as "how disagreements are handled among people here". Whenever there are different views and conflicting proposals, the process of generating the outcome is the governance, it could be autocratic, democratic, dictatorship, other types or combination of types. One can only avoid governance in a place where there is no diverse views and highly homogeneous, or when no decisions needs to be made "together". In the Ethereum EIP and many open contributor communities, the key characteristic, both good and evil, is that contributors often hold different views, and hence governance can't be avoided unfortunately.

If you see that quit editorship didn't solve your problem, consider re-take your editorship? 👍

IMO finalized is a trailing indicator of something else that is much more useful: what hard fork the EIP was included in. I think rather than finalized-date, the tag should be network-upgrade or something similar.

In theory, Core EIPs should become final as of the hard fork they are included in, so this should functionally be the same.

We sidestep "governance" issues in this repository by making it so anyone can create an EIP and move it to final, as long as it satisfies a set of pretty strict requirements. There is no need to decide who/what is right, all EIPs are treated exactly the same.

Should we reinstate meta-fork EIPs?

I have no strong opinion about a finalized field, but would absolutely love a fork or block-number type field.

The argument against including it, @MicahZoltu, is because an alternate chain could choose not to include a certain EIP (or fork it out) and by including that information we're participating in governance?

As long as the EIP authors are responsible for including the field EIP editors aren't participating in governance.

an alternate chain could choose not to include a certain EIP (or fork it out) and by including that information we're participating in governance?

That is one of the reasons. ETC used to use the EIP process (not sure if they do anymore). Generally speaking, if one believes that fork based governance is a good idea, we want as few systems to be "fork specific" as possible to encourage healthy community splits. If one community gets to keep all of the associated development processes that has a very significant impact on the perceived legitimacy of the other fork. Essentially, it creates an avenue for governance capture by allowing one more thing to be involved in the decision making process of which branch of a fork is legitimate.

In a perfect world, all processes would be generalized such that in a community split there are no assets/processes/resources to fight over as it is all generic.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

would absolutely love a fork or block-number type field

I am also a strong supporter of having one of these fields. This would improve the UX of the EIPs repo much more than it would restrict people from forking processes. As I've said in the past, our responsibility is for what is considered "Ethereum mainnet" today. We shouldn't needlessly encumber ourselves by optimizing for the extremely unlikely scenario that mainnet is i) forked and ii) the opposing chain wants to continue using this exact repository for their governance.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

Dismissing stale bot.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

Dismissing stale bot.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

Dismissing stale bot.

Following academic citation guidelines (so we're indexed in Google Scholar) is actually a pretty decent reason on its own to support adding finalized.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.