Problem
Since the EIPs/ERCs split, both repos carry ~50 shared infrastructure files that have drifted independently. Concrete evidence from a side-by-side audit:
CI is actively papering over the split. EIPs/.github/workflows/ci.yml now checks out the ERCs repo and merges it in before running eipw (commit 20917c10: "CI: Fix EIPW check by merging ERCs prior to running"). jekyll.yml in EIPs runs a ./.github/actions/merge-repos step on a 15-min schedule. The infra already treats them as one logical repo — just awkwardly.
Linters are intentionally broken to tolerate the split. config/eipw.toml in ERCs contains comments like "Disabled due to EIP/ERC repo split", with cross-repo lints turned off. The two eipw.toml files (940 vs 942 lines) are otherwise nearly identical.
Templates and contributor docs have drifted, not by design.
eip-template.md (130 lines) vs erc-template.md (120 lines): ERCs lost the "Chain Specifics" section and RFC link formatting, and picked up a "may be be" typo.CONTRIBUTING.md exists only in EIPs (130 lines). ERCs has no contributor doc.README.md: 87 lines (EIPs) vs 26 lines (ERCs)._layouts/eip.html: EIPs has full ERC/EIP category-switching logic; ERCs has it simplified/commented out._includes/: 3 of 8 files diverge (eiptable.html, head.html, toc.html).
Maintenance is unsynced. ci.yml commit histories after the split share zero commits — EIPs commits focus on eipw tooling fixes, ERCs commits on artifact handling and Ubuntu upgrades. _config.yml shared 10 commits up to ~2–3 years ago, then a single split-commit, then silence on the ERCs side.
Content vs infra ratio: 919 eip-*.md files, 585 erc-*.md files, ~50 duplicated infra files maintained twice.
Proposal
Consolidate the shared surface so each repo owns only proposal content plus genuinely repo-specific config. Options worth discussing:
- Shared infra repo consumed via submodule or release tag.
- Generated mirror: one canonical source; CI publishes the other.
- Monorepo with two Jekyll site builds; routing handled at GitHub Pages / DNS.
Option 2 is closest to what merge-repos already does on a schedule — it just isn't the source of truth.
Ask
Editor feedback on (a) whether consolidation is wanted, and (b) which of the three structures is acceptable, before anyone invests in the migration PRs.
Problem
Since the EIPs/ERCs split, both repos carry ~50 shared infrastructure files that have drifted independently. Concrete evidence from a side-by-side audit:
CI is actively papering over the split.
EIPs/.github/workflows/ci.ymlnow checks out the ERCs repo and merges it in before runningeipw(commit20917c10: "CI: Fix EIPW check by merging ERCs prior to running").jekyll.ymlin EIPs runs a./.github/actions/merge-reposstep on a 15-min schedule. The infra already treats them as one logical repo — just awkwardly.Linters are intentionally broken to tolerate the split.
config/eipw.tomlin ERCs contains comments like "Disabled due to EIP/ERC repo split", with cross-repo lints turned off. The twoeipw.tomlfiles (940 vs 942 lines) are otherwise nearly identical.Templates and contributor docs have drifted, not by design.
eip-template.md(130 lines) vserc-template.md(120 lines): ERCs lost the "Chain Specifics" section and RFC link formatting, and picked up a "may be be" typo.CONTRIBUTING.mdexists only in EIPs (130 lines). ERCs has no contributor doc.README.md: 87 lines (EIPs) vs 26 lines (ERCs)._layouts/eip.html: EIPs has full ERC/EIP category-switching logic; ERCs has it simplified/commented out._includes/: 3 of 8 files diverge (eiptable.html,head.html,toc.html).Maintenance is unsynced.
ci.ymlcommit histories after the split share zero commits — EIPs commits focus on eipw tooling fixes, ERCs commits on artifact handling and Ubuntu upgrades._config.ymlshared 10 commits up to ~2–3 years ago, then a single split-commit, then silence on the ERCs side.Content vs infra ratio: 919
eip-*.mdfiles, 585erc-*.mdfiles, ~50 duplicated infra files maintained twice.Proposal
Consolidate the shared surface so each repo owns only proposal content plus genuinely repo-specific config. Options worth discussing:
Option 2 is closest to what
merge-reposalready does on a schedule — it just isn't the source of truth.Ask
Editor feedback on (a) whether consolidation is wanted, and (b) which of the three structures is acceptable, before anyone invests in the migration PRs.