Add EIP: ERC/EIP Repository split

Merged by EIP-Bot.

EIPS/eip-7329.md

@@ -0,0 +1,245 @@
+---
+eip: 7329
+title: ERC/EIP Repository split
+description: Split the ERC specifications out of the EIP repository into a new repository, so that only core protocol EIPs remain
+author: Lightclient (@lightclient), Danno Ferrin (@shemnon)
+discussions-to: https://ethereum-magicians.org/t/eip-erc-repo-split/15053
+status: Draft
+type: Meta
+created: 2023-07-13
+requires: 1
+---
+
+## Abstract
+
+Describes the motivation and rational for splitting the EIP process into an EIP
+Process, targeting core ethereum changes and an ERC process, targeting
+application layer specifications.
+
+## Motivation
+
+Long ago when the EIPs repository was created, there was a vision of a single
+home for all standards related to Ethereum. The community was small and most
+people were interacting at every level of the stack. It made sense to combine
+application standards with core consensus changes.
+
+Since then, the ecosystem has grown. Today, the chasm between application
+development and core development is wide. Fewer people are involved across the
+stack (for better or worse); yet the repository remains unified.
+
+For years, we've considered separating the repository. This would allow ERC and
+EIP processes to evolve more naturally due to the independence. But it's always
+difficult to reach critical threshold to make a change like this happen. Each
+time we get lost in the details of the migration and the debate grinds progress
+to a halt.
+
+Now that the Consensus Layer is also utilizing the EIP process, the cracks are
+becoming more visible. There are changes we could make to the process that might
+benefit them more, but because we also need to ensure the quality of ERCs, we
+are restricted.
+
+There are also many more efforts to catalyze applications around the ERC
+process. Attempts have been made to develop working groups and review groups for
+certain ERC "categories" (a distinction that doesn't even technically exist
+because of the unified repo).
+
+## Specification
+
+This specification only details with the initial mechanism of the split. The
+particulars of how each repository will govern itself is out of scope for this
+EIP, as it is the motivating point of the EIP that the divergent needs of the
+community will require highly divergent methods.
+
+1. All ERCs are removed from this repository and migrated to a new repo. The
+   history should be intact so that repo should be forked of this one with the
+   non-ERCs removed. I've written a script (see below) to perform this
+   operation. Once this PR is approved, it should be executed immediately before
+   merging.
+2. The new ERCs repository goes live and includes the changes from the script.
+3. Setup ercs.ethereum.org subdomain and update the CI to point to the ERCs
+   repo.
+4. Set up a redirect for ERCs on eips.ethereum.org to go to the new website.
+5. Create a unified document for editors to assign EIP/ERC numbers. EIPs and
+   ERCs will no longer be based on an initial PR number but on a number
+   incremented by the EIP editors of their respective repositories. EIPs will be
+   assigned even numbers and ERCs will be assigned odd numbers. The exact
+
+## Rationale
+
+There are two major communities served by the EIP process that are highly
+divergent and very differentiated in their needs.
+
+Let's consider the impact of specification ambiguity, the impacts are different
+based on the community. The core protocol community has a low tolerance for
+difference of implementation and a high penalty for specification ambiguity. An
+improperly implemented part of a new spec could cause the ethereum mainnet to
+split, possibly costing millions to billions of value lost to node operators as
+well as community members using the services offered by the Ethereum protocols.
+A poorly specified solidity interface, however, can be adapted and implemented
+in multiple compatible ways across any smart choosing to implement it. A missing
+RPC API (such as a configuration option specifying the number of decimals in the
+chains native currency) can have limited to zero impact on the rest of the
+community not choosing to use that wallet.
+
+Timeframe for delivery of a feature is also similarly differentiated. A Core
+protocol EIP adjusting the gas cost for transaction data needs to be rolled out
+at a specific time uniformly across the network. Whereas a new RPC to support
+new semantics to gas estimation would not need uniform rollout across the
+Ethereum clients, and in fact would also need to be rolled out by service
+provides that provide RPC services for Ethereum networks. Wallets can use early
+support as a differentiating factor in their appeal to community members.
+
+To address this divergence the AllCoreDevs call has adopted a lifecycle for EIPs
+different from the Draft -> Review -> Last Call -> Final lifecycle of the EIP
+repository. It would best be describe as Draft -> Eligible for Inclusion ->
+Considered for Inclusion -> Testnet -> Mainnet. The EIPs also get slotted for a
+fork in the third step, a consideration that simply does not apply to a smart
+contract or wallet standard.
+
+Several alternatives have been proposed, but the actual implementation only
+further underscores the specialization that each side of the split encounters.
+
+### Alternative: Working Groups
+
+One repeated concern of editors is that they often lack the technical experience
+to adequately judge if an EIP is complete and sound. Considering that EIPs
+covers wide variety of topics such as elliptic curve cryptography, VM
+performance, DeFi market dynamics, compression protocols, NFT Royalties, and
+consensus protocols it is impossible for a single editor to provide sensible
+feedback on every one of those topics.
+
+When examining how the core protocol and ERC communities would approach the
+working group process, however, it underscores how different they would handle
+it. For core protocol change the working group would be one of the two
+AllCoreDevs meetings, either AllCoreDevs-Execution or AllCoreDevs-Consensus. And
+sometimes both. There is no EIP that would be shipped in mainnet that would not
+first be extensively considered by one of these two groups.
+
+ERC proposals have no such standing groups. Wallet impacting changes may go
+through the AllWalletDevs group, but it is entirely possible for a wallet or
+group of wallets to collaborate on a protocol outside AllWalletDevs. Smart
+contract APIs have no such standing meeting.
+
+The Working Group model, however, would be a critical social signal for the ERC
+community. It would signal a critical mass for a particular proposal issue if
+enough experts could get together to agree to review a set of changes.
+
+While working groups are excellent for the ERC community, it is overhead for the
+core protocol community that would only add friction to an already established
+process with know governance checkpoints.
+
+### Alternative: Specialized Editors
+
+This alternative has [already been implemented](../config/eip-editors.yml).
+There has been no measurable impact on the divergence of the community. Most
+categories have a significant overlap with other categories.
+
+This alternative does not address the governance and workflow issues that the
+Core Protocol Developers would want to implement. All subgroups would still be
+subject to the same workflow as other groups.
+
+### Alternative: Pain unrelated to process divergences
+
+This is a catch-all for a number of proposals, from allowing discord links in
+discussion-to to allowing more freedom in external links.
+
+While the theory that this may reduce the total amount of pain felt by users and
+editors, bringing the pain level down to a more acceptable level, this does not
+address the core divergence issue. Many of these pain relief proposals should
+probably be done anyway, weather or not the EIP repository splits.
+
+### Alternative: Replace EIP Editors with AI Chatbots
+
+Nobody wins in this proposal. We would instead end up debating training sets,
+competing implementations, and whether to use commercial providers. And
+that's if things go well.
+
+AI chatbots, however, would not be able to compartmentalize the divergent needs
+of the multiple groups if all adjudication were to be handled with one model or
+one chat session. Higher quality output would be received if separate training
+repositories were used for each major functional area.
+
+### Alternatives are not Mutually Exclusive
+
+It is critical to note that most of the discussed alternatives all have merits
+and address important pain points. The adoption of a split should not be viewed
+as a rejection of those alternatives. To quote a famous internet meme "Why Not
+Both?"
+
+### Objection: This splits the ethereum community
+
+One objection is that splitting the repository would result in the community no
+longer being able to say "we are all of us Ethereum Magicians."
+
+First it is important to note that such splits are already occurring. The
+AllCoreDevs call has split into a Consensus and Execution layer call. ACD calls
+no longer discuss client issues like wallet apis, the AllWalletDevs call has
+adopted those issues and has grown into user experience issues. Cross chain
+issues have been adopted by the Chain Agnostic Improvement Process (CAIP) group.
+
+Rather than splitting this should be viewed as "sharding", where a sub-community
+of interest rallies around a shared sub issue, and by gathering are able to
+increase the total scope of the community. CAIP is a perfect example where
+operating separate from EIPs have allowed them to strengthen the ethereum
+community.
+
+Is a single cell organism weakened when it grows large and then splits into two?
+Is an animal weakened when cells split and specialize into different tasks? It
+is this very act of division and specialization that allows it to accomplish t
+things that would be impossible as a single uniform cell.
+
+### Objection: This should be an  [EIP-1](./eip-1.md) proposal
+
+Since this is directly impacting the ERC process it should be documented
+in  [EIP-1](./eip-1.md) first.
+
+As the old programming adage goes: "Refactor first before adding any new
+features."  Adding new processes specific to the post-split governing docs would
+only confuse the existing process, adding special cases for one class of EIPs
+that don't apply to another. It is precisely this kind of problem the proposed
+split is aiming to change.
+
+This is also valid grounds for a Meta category EIP, as how many and which
+repository to put a proposal in is core to the "procedures, guidelines, \[and\]
+changes to the decision-making process".
+
+Some process changes that can be expected in a Core Protocol EIP may include:
+
+* Changing the work flow to add the Eligible for Inclusion/Considered for
+  Inclusion stages to a pre-last-call EIP.
+* Adding test net and mainnet steps to the lifecycle
+* Adding a "fork" header to the RFCs section, for EIPs that are (or will be)
+  implemented in a specific fork
+* Changing the testing section to a header link to reference tests
+
+Some process change ERC may want to adopt:
+
+* A strong working group model and adding an optional "forming working group"
+  step editors may require.
+* Add an "outdated" or "replaced" lifecycle step for EIPs that are abrogated by
+  future specs.
+* Deputize single-eip reviewers for specific EIPs
+
+## Backwards Compatibility
+
+### Old Links
+
+Old ERC links pointing to the old url `https://eips.ethereum.org/` will continue
+to work. Redirect instructions will be put into place to redirect to the new ERC
+repos for their corresponding location.
+
+### Stray Proposals
+
+ERC community members may continue to post new ERCs in the EIP proposal. Editors
+will be able to redirect them to the new repository. ERCs that do not respond to
+editor requests would not be merged anyway.
+
+## Security Considerations
+
+This proposal only addresses the EIP and ERC proposal process and is not
+expected
+to expose any new attack surfaces by virtue of its adoption.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).