@shemnon We are at the end of Last Call, and as a Meta proposal I have no big problems with this – moving this EIP to Final doesn’t necessarily mean we merge Move ERCs to separate repository by lightclient · Pull Request #7206 · ethereum/EIPs · GitHub, and it lays out that proposal well. Thanks.
I think our fundamental disagreement starts here:
For years, we’ve considered separating the repository. This would allow ERC and EIP processes to evolve more naturally due to the independence.
Although you speak of repositories and processes, the deeper issues are around people and governance. In particular, does splitting the repositories mean splitting the Editors into separate organizations? It’s your proposal, so I’m not asking you to change your intent. However,
If you intend to split the Editors into two organizations you should be explicit. This is the only change I really want to see before this goes to Final.
It is of course the organizational split that I most object to.
I think the most insightful comment on this is from @bumblefudge here. In part:
But notice the subtle slide from “split the repos” to “split the editorial processes into two separate deciding bodies with different processes.” I think the pushback comes from the distance between those two changes. This PR only splits the repos, with a sort of implicit promise that the processes can evolve separately down the road, and if I’m reading correctly the objections, it’s the uncertainty of this future step that is giving people pause, and/or the “overpromising” that severing the process helps both halves work better in the near future … bifurcating the process might be trading ONE can of worms for TWO …
I do think there are some misunderstandings of the Pain relief work in progress that might be worth correcting. In particular, you write:
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 known governance checkpoints.
I am trying to reduce overhead by saying that the Core Developers are already a de facto working group. And I’ve said in a few places that I’m trying to reduce the friction by getting the Editors “out of the workflow business”. A working group itself defines it own governance and the stages of its own processes. So I’ve proposed a separate working-group-status header to use for those governance checkpoints. (We could allow working groups to use the existing Status header instead.)
As I wrote here:
I’m proposing that once an EIP is a Draft the Core Developers will have full control – in the sense that the EIP need not meet Editorial standards again until it goes to Final, which can happen after the upgrade. And the standards for Draft should be reasonably low. That way the Editors should never be in the position of blocking an upgrade.
And I’m slightly off on not meeting Editorial standards – minimal standards on format are needed to be sure the draft renders OK on https://eips.ethereum.org.