Update EIP-7329: Move to Review

Merged by EIP-Bot.

EIPS/eip-7329.md

@@ -4,17 +4,16 @@ 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/proposal-forking-ercs-from-eips-repository/12804
-status: Last Call
-last-call-deadline: 2023-07-31
+status: Review
 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
+Describes the motivation and rational for splitting the EIP repositories into an
+EIP repository, targeting core ethereum changes and an ERC repository, targeting
 application layer specifications.
 
 ## Motivation
@@ -29,10 +28,10 @@ development and core development is wide. Fewer people are involved across the
 ecosystem (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.
+EIP specifications 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
@@ -48,7 +47,7 @@ because of the unified repo).
 
 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
+EIP, as it is the motivating point of this 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
@@ -63,7 +62,25 @@ community will require highly divergent methods.
 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
+   assigned even numbers and ERCs will be assigned odd numbers. The exact timing
+   of this migration is a policy decision of the editors.
+
+The EIP repository will be associated with core protocol changes, specifically
+the kind that would be discussed in one of the AllCoreDevs calls; whereas the
+ERC repository will be affiliated with all remaining areas such as smart
+contract application interfaces, wallet standards, DeFi protocol standards, and
+all other such improvements that do not require core protocol changes.
+
+This association is to persist across any other process changes the EIP editors
+may introduce such as working groups, topic groups, expert groups, special
+interest groups, splitting of the process, or other such changes. Any
+sub-groupings that includes core protocol changes would be associated with the
+EIP repository and other sub-groupings are associated with the ERC repository.
+Any such process change are out of scope of this EIP and are independent of the
+structural changes to the repositories specified in this EIP.
+
+There may be further structural changes to repository layouts to accommodate
+more sub-groupings. Such proposals are out of scope of this EIP.
 
 ## Rationale
 
@@ -92,7 +109,7 @@ 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 ->
+repository. It would best be described 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.
@@ -189,7 +206,7 @@ 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
+is this very act of division and specialization that allows it to accomplish the
 things that would be impossible as a single uniform cell.
 
 ### Objection: This should be an  [EIP-1](./eip-1.md) proposal
@@ -224,6 +241,16 @@ Some process change ERC may want to adopt:
   future specs.
 * Deputize single-eip reviewers for specific EIPs
 
+### Objection: Structural changes to a repository and process changes do not need to be bundled.
+
+It is possible to split the structure of the repositories separately from any
+EIP process changes related to this. Bundling the changes is unnecessary and
+such structure and process changes should be handled independently.
+
+To accommodate this objection this EIP has been revised to only address
+structural changes in the repository and can be adapted to any other,
+independent, process changes and mapped onto those outcomes.
+
 ## Backwards Compatibility
 
 ### Old Links
@@ -241,8 +268,7 @@ 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.
+expected to expose any new attack surfaces by virtue of its adoption.
 
 ## Copyright