EIPIP Meeting 13 Agenda about eipip HOT 13 CLOSED

I would like to propose that there is a discussion about constraining the EIP repository scope. @poojaranjan just pointed out to me elsewhere that a recent EIPIP meeting resulted in the recommendation to use the EIPs repository as a storage vault for mainnet operations retrospectives, but to me that feels like pretty big scope creep, and somewhat contrary to the idea of getting Ethereum mainnet stuff out of the EIPs repository (like the hardfork meta EIP).

I would like to see this repository be just standards, and anything else can live somewhere else. EIP editors are all volunteer and already way overstretched with work. I think we should be looking into how we can cut scope, not add scope. An example of how we can cut scope would be to extract ERCs into a separate repository and get hardfork consensus process out of this repository.

from eipip.

I've spent some time reflecting on the discussion last meeting regarding the separation of the EIP process and the network upgrade process. I understand and agree with the desire to separate the two processes. I believe that the network upgrade consensus process requires different parties and must address different concerns than the finalization of specs. However, I disagree that the EIPs repository should not acknowledge the importance of an EIP landing on mainnet. It is valuable to look at an EIP and quickly determine if it is the current state-of-the-art (on mainnet). There is no reason to not mark mainnet EIPs as "state-of-the-art". If the network upgrade process is truly separate, then it is simply a bookkeeping task that the author / editors must undertake to update the metadata. With better tooling, it can even be automated. I urge us to take another look at the statuses and decide upon a name for a new status that denotes an EIP has been deployed to mainnet.

--

On another note, there are a lot of other aspects of the EIP process that can be improved. However, I believe that many of those will dissipate if we address the lack of ownership that currently exists in the process. While our protocol must be tustless and resistant to censorship, the default avenue in our standardization process does not necessarily need to embody those principles. Without any ownership in the process, there is little desire to improve it. It becomes a tragedy of the commons.

I would like us to explore the idea of working groups. Essentially all standardization organizations have them--Ethereum shouldn't be special in this regard. We already have them informally. We should acknowledge them explicitly and give them ownership of their track (again, this is separate from network upgrade coordination). Editors can focus on generic EIP requirements and act as custodians of the repository, while working groups should help direct resources and ideas towards existing efforts. Working groups shouldn't be gatekeepers. They should have high level goals and help elevate new ideas and participants which align with their goals by connecting them to resources which can help them accomplish their goals. A quick sketch of a few working groups I envision:

I believe that establishing working groups will not only help relieve some of the duties of EIP editors, it will improve the quality of EIPs in the repository and increase the velocity of ideation and collaboration. If others believe that this would be valuable step to make, I would be happy to flesh it out more and shepherd its adoption.

from eipip.

Agenda Item: Does anyone oppose adding this standard citation format to the footer of all EIPs?
ethereum/EIPs#2738

from eipip.

Agenda Item: Does anyone oppose adding this standard citation format to the footer of all EIPs?
ethereum/EIPs#2738

Added to the agenda!

from eipip.

However, I disagree that the EIPs repository should not acknowledge the importance of an EIP landing on mainnet. It is valuable to look at an EIP and quickly determine if it is the current state-of-the-art (on mainnet).

To be clear, I think documenting mainnet operations and what is state-of-the-art on Ethereum mainnet is incredibly important. I only disagree that such things should live in the EIPs repository.

I suspect this difference of opinion stems from a difference in belief in what the purpose of EIPs are. If you believe that EIPs are specifically related to the chain known as Ethereum, then your stance has much more strength. If you believe that EIPs are a place to standardize things which may be used on Ethereum, but may also be used on Ethereum Classic, or any other of the Ethereum-like chains then I think my stance is strengthened.

I'm in the camp that the purpose of the EIPs repository should be to standardize things that make sense on any Ethereum-like chain, which includes Ethereum 1.x, Ethereum Classic, Ethereum 2.x, etc. and this means that sometimes stuff will be final without ever making it to Ethereum mainnet, but that doesn't mean it isn't state of the art.

Another thing to keep in mind is that eventually Ethereum 1.x will diverge from Ethereum 2 and so "state of the art" will become pretty fuzzy even for Ethereum mainnet since there will, effectively, be two Ethereum mainnets.

from eipip.

I suspect this difference of opinion stems from a difference in belief in what the purpose of EIPs are. If you believe that EIPs are specifically related to the chain known as Ethereum, then your stance has much more strength. If you believe that EIPs are a place to standardize things which may be used on Ethereum, but may also be used on Ethereum Classic, or any other of the Ethereum-like chains then I think my stance is strengthened.

I think you stated the differences well. Hopefully from my original post my stance is clear -- I believe the EIPs repo should be a place for Ethereum standards.

Another thing to keep in mind is that eventually Ethereum 1.x will diverge from Ethereum 2 and so "state of the art" will become pretty fuzzy even for Ethereum mainnet since there will, effectively, be two Ethereum mainnets.

Although this is true in the shorter term, there will eventually be a consolidation and there will be only one Ethereum mainnet. I don't think we should overcomplicate things in the interim. Therefore, I continue to believe that the EIPs repo should be solely focused on Ethereum.

from eipip.

@poojaranjan Can we move talking about the Network Upgrade process first? I think it's a priority, more than the other tasks. I'd like to get the process spec'd out and finished soon, before tackling onboarding and EIP document format.

from eipip.

If possible, I'd prefer we kept items like:

• Working groups
• Onboarding editors
• EIP sections

in the project board until the decision-making process is finalized.

from eipip.

I'd also like to propose a process we can use to create solutions for the Network Upgrade spec.

from eipip.

Agenda item: Transform the current EIP-1 standards to a table format. This is based off of Edson's link to the javascript process https://tc39.es/process-document/

from eipip.

generally speaking, working groups are outside of the scope of the EIPIP group. It'd be a good topic to discuss ECH project submissions (e.g. forming a framework for working groups); I think ECH would need more funding to give another group the focus, organization, and documentation it deserves, though.

from eipip.

@poojaranjan Can we move talking about the Network Upgrade process first? I think it's a priority, more than the other tasks. I'd like to get the process spec'd out and finished soon, before tackling onboarding and EIP document format.

Rearranged the agenda. However, the group is free to shuffle items as per the availability of the proposer and agreement on the topic to be discussed during the meeting hour.

from eipip.

Closing in favor of #26

from eipip.