Separating EIPs and ERCs

ligi · November 9, 2018, 3:26pm

As this was just briefly topic at the end of the AllCoreDevs meeting just now (and the idea there was also to bring it up here) - I am opening this discussion with this post. I am still a very big fan of this idea. Started an initiative for this a while ago:

People liked it (just some bike-shedding around the naming) - but I am not sure about how to roll this change out - this was also the reason I did not proceed with it. If anyone has an idea how to actually roll this out: please shoot!

boris · November 9, 2018, 9:58pm

Run both in the EIPs repo. But have more clearly defined separate tracks. Have ERC editors separate from EIP editors (although both have power to help each other out with the basics).

I have an edit in progress to track and bring in more specifications — JSON-RPC, devp2p, whisper. So that everything to build a compliant and compatible Ethereum client is in one place.

github.com

spadebuilders/EIPs/blob/specs-and-standards/README.md

# EIPs [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.

A browsable version of all current and draft EIPs can be found on [the official EIP site](http://eips.ethereum.org/).

# Standards and Specifications

Aside from improving and upgrading the Ethereum platform, the goal of the EIP process is to document the standards and specifications that define it. Following these specifications, an implementation team should be able to build interoperable components that connect to the Ethereum main net, various test nets, and other layers of the Ethereum network.

The list of Ethereum components is as follows. Each component may have a different process for maintenance and updates, but will create or update EIPs to reflect changes.

<!-- EDITORS / MAINTAINERS for each of the below -->

* formal specification https://github.com/ethereum/yellowpaper <!-- TO BE REPLACED with Jello Paper -->
* devp2p https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol
* Light Ethereum Subprotocol https://github.com/ethereum/wiki/wiki/Light-client-protocol
* whisper https://github.com/ethereum/go-ethereum/wiki/Whisper-Overview
* swarm https://github.com/ethereum/go-ethereum/pull/2959
* API/RPC https://github.com/ethereum/wiki/wiki/JSON-RPC
* contract ABIs https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI

This file has been truncated. show original

I’m up for discussing and helping with this.

ligi · November 10, 2018, 10:25pm

I think they should not reside in the same space. Really separating them has some advantages - e.g. something trivial like smaller numbers that are easier to remember - also I think it makes the process more agile as one group can move/change processes without influencing the other one.

boris · November 11, 2018, 5:50am

So, separate repos for each type of specs? I’m not super tied to one approach or the other, but i believe that there aren’t enough people involved in the process today, and splitting it means there will be even less.

And that coordinating in general will be harder.

Do you have some specific thoughts of how this would work? How do we brainstorm approaches?

More broadly — who cares enough to help?

ligi · November 11, 2018, 10:01am

Ya - splitting it in very fine granularity would not be good. I would just split in 2 parts (for now) - EIPs and contract interfaces. In the EIPs we could still go track route you suggested. But I think contract interfaces should be really split out already.