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.

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

EIPIP Meeting 13 Agenda #25

Closed
poojaranjan opened this issue Jul 20, 2020 · 13 comments
Closed

EIPIP Meeting 13 Agenda #25

poojaranjan opened this issue Jul 20, 2020 · 13 comments

Comments

@poojaranjan
Copy link
Member

poojaranjan commented Jul 20, 2020

Date and Time

Wednesday, July 29, 2020, at 15:00 UTC

Location

Zoom: The link will be shared in the telegram group.
YouTube Live Stream/Recording - https://youtu.be/8dxGtomafP4

Agenda

1. Network upgrade process

2. Onboarding EIP editors

  • survey to set expectations of an EIP Editor
  • triaging permission

3. New EIP validator and a suggestion to handle current validator

4. Standard citation format to the footer of all EIPs

5. Constraining the EIP repository scope

6. Discussion on Muir Glacier postmortem report PR-2809 and Network upgrade postmortem template PR-2810

7. Explore the idea of working groups

8. Clarifications for how a precompile address is decided.

9. Discuss the EIP-1 Brainstorming Document

  • Goals Outcomes
  • What we are not doing.
  • EIPs TODO

10. Review action items from previous meeting

Next Call - Aug 12, 2020.

@MicahZoltu
Copy link

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

@poojaranjan
Copy link
Member Author

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

Added to the agenda!

@MicahZoltu
Copy link

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.

@lightclient
Copy link

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:

What Who Goals
Meta This group + editors Maintain EIP-1, facilitate work group processes, maintain and develop tools to improve the EIP process
EVM EVM devs Improve the EVM and study the effect of changes to it
Clients Core devs Improve client design and development, reduce resources needed to operate clients
Networking devp2p devs Improve the networking infrastructure of the Etheruem network
ERC Authors of existing ERCs, defi folks Design token standards and maintain interoperability across various standards
RPC web3 library maintainers / dapp devs Improve the interface between application developers and clients
Eth 1.x The eth 1.x group Research and propose the optimal path to transitioning eth1 to a more stateless network
Eth 2.0 The eth 2 research + client teams Design and develop the Ethereum 2.0 protocol, propose and review changes needed in the eth1 protocol
... ... and more

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.

@MicahZoltu
Copy link

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.

@lightclient
Copy link

lightclient commented Jul 28, 2020

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.

@edsonayllon
Copy link
Contributor

edsonayllon commented Jul 28, 2020

@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.

@edsonayllon
Copy link
Contributor

edsonayllon commented Jul 28, 2020

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.

@edsonayllon
Copy link
Contributor

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

@alita-moore
Copy link
Contributor

alita-moore commented Jul 28, 2020

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/

@alita-moore
Copy link
Contributor

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.

@poojaranjan
Copy link
Member Author

@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.

@poojaranjan
Copy link
Member Author

Closing in favor of #26

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants
@MicahZoltu @lightclient @alita-moore @poojaranjan @edsonayllon and others