EIP/ERC process improvement

[axic]

I think this is happening de facto already, but can we codify that:

• proposals can be referred to as ERC<n> where n refers to the issue number
• final EIP numbers are allocated when an ERC is accepted

Additionally, can we also introduce the following Github labels?

• scheduled (for discussion in the next core dev meeting)
• concept accepted / prototyping (design is accepted, need to/should be prototyped in multiple clients)
• rejected
• accepted (it must become an EIP, where changes are allowed)

Alternatively we could also just follow the process described in EIP0 😃

[cdetrio]

I'd also like to see labels for the different EIP categories.

In EIP1 the "Standard Track" had two categories: Consensus and Networking. Then EIP4 expanded that to four "layers": (1) Consensus, (2) Networking, (3) API/RPC, and (4) Applications.

I suggest refining these four categories under the following labels: (1) "core", (2) "networking", (3) "interface", and (4) "standard".

1. core: includes improvements requiring a consensus fork (e.g. EIP5, EIP101) and also changes that are not necessarily consensus critical but still most relevant to "core dev" discussions (for example, EIP90, and the miner/node strategy changes 2, 3, and 4 of EIP86).
2. networking: includes improvements around devp2p (EIP8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.
3. interface: includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP59, EIP6) and contract ABIs. The label "interface" aligns with the interfaces repo. Would include EIP144, EIP136, EIP130, EIP95, EIP94, EIP80, EIP60, and EIP50.
4. standard: an abbreviated label for application-level standards and conventions, including contract standards such as token standards (ERC20) and name registries (ERC26, ERC137). Would also include proposals for URI schemes (ERC67), library/package formats (EIP82), and wallet formats (EIP75, EIP85).

[Souptacular]

I think @cdetrio's and @axic's ideas are good. Here is my culmination of the proposed changes.

• proposals can be referred to as ERC where n refers to the issue number
• proposals change from ERC to EIP, by way of the issue title being changed.
• status/labels should follow this https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-status-field (maybe with some modifications to make it simpler)
• add scheduled label (for discussion in the next core dev meeting)
• Change the categories to those described by @cdetrio.

It would be great to get other feedback for changes. I aim to implement the above changes (if agreed upon) in the next week.

[Arachnid]

proposals change from ERC to EIP, by way of the issue title being changed.

I think ERC and EIP are (or should be) two different things. An ERC is a general protocol proposal for the Ethereum ecosystem, and doesn't require consensus changes. An EIP involves a change to the Ethereum protocol. We could potentially dump the 'ERC' nomenclature and expand 'EIP' to cover everything, but I think it would be misleading to treat them as different stages of the lifecycle of the same thing - they're both "Proposals", after all.

status/labels should follow this https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-status-field (maybe with some modifications to make it simpler)

The issue tracker is really a terrible way to maintain EIPs, and I was really hoping we could move off it. In the issue tracker, only the original author can modify the EIP, and they can do so without review or notification, and with no way to see past versions of the EIP. The discussion thread adds a lot of noise, and on some EIPs makes it difficult to determine what the canonical version of it is.

My suggestion would be to return to using the repository to track EIPs, with PRs for submissions and changes. With this, we can easily add Jekyll support to automatically generate a 'standards site' from it - see https://github.com/pidcodes/pidcodes.github.com and http://pid.codes/ for an example of this; I'm happy to help set it up.

[axic]

I think ERC and EIP are (or should be) two different things. An ERC is a general protocol proposal for the Ethereum ecosystem, and doesn't require consensus changes. An EIP involves a change to the Ethereum protocol.

I this a new definition you are proposing?

The ERC/EIP split currently tries to address the problem you mention that Github issues are a terrible way to track these. I agree that moving on from the issue tracker can be a better solution.

However, purely moving to pull requests will not solve the numbering issue. People will start using the pull request number as the EIP number. There must be a process in place to assign EIP numbers to proposals.

---

If we are following BIPs, that has three categories: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-types

All concensus, and many of the non-concensus changes fit into:

A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
In short, it only has BIP, which fits both ERC and BIP

According to EIP4, we already expanded EIP to cover all these:

In EIP1 the "Standard Track" had two categories: Consensus and Networking. Then EIP4 expanded that to four "layers": (1) Consensus, (2) Networking, (3) API/RPC, and (4) Applications.

[Arachnid]

I this a new definition you are proposing?
The ERC/EIP split currently tries to address the problem you mention that Github issues are a terrible way to track these. I agree that moving on from the issue tracker can be a better solution.

It's a distinction I've seen raised before, but not formalized anywhere: the idea that an ERC is a new specification for something that doesn't affect consensus, and an EIP is a protocol improvement. I'm happy to ignore that and call everything an EIP, personally.

[axic]

@Arachnid I see. The other idea I have seen is that when a proposal is made, it is for request for comments and when an initial concensus formed that it is useful, it can become an EIP (ie. moving on from an issue to a pull request). Agreeing with you, this is only trying to solve the lack of process for obtaining EIP numbers.

[gcolvin]

My opinions:

1. Stick with calling every thing an EIP.
2. Number EIPs by their issues permanently. Easier to remember, and it keeps the numbered issues lists available for ongoing discussion of the EIP.
3. What layer they belong to (and what layers there are) is itself up for discussion.
4. Summary comments can be placed among the other comments by those who care to.
5. Long issues discussions are not a problem. Github handles them well, with every comment timestamped and given an URL, and every poster given a tag. (I archive them all to email myself.)

[Souptacular]

So currently the consensus is that EIPs should move from issues to PRs.

I also feel like most people agree that EIP numbering should be based on the PR number (currently it is based on the issue #), with the exception of issue numbers that are already assigned if we are to migrate from issues to PRs. So for instance, EIP 150 will remain EIP 150 even if it moves to a different PR number, but in the future new EIPs will be assigned by PR number.

[gcolvin]

Well, I'm not with it, as I said above. As Github goes, the current layout is easy enough to navigate, and the history of modifications to each EIP file is clear. Only question is how to number EIPs as they emerge from the issue discussions, and we might as well call them by their issue numbers, since we've been calling these issues EIPs anyway. Why start over?
I'm not hard over opposed, I just don't understand the proposal enough to judge. I'm not clear how things would look and be navigated in this new PR scheme - but it sounds more complicated. And we'd best start calling the issue discussions that precede the crafting of EIPs something else.

[Arachnid]

As Github goes, the current layout is easy enough to navigate, and the history of modifications to each EIP file is clear.

Unless I'm missing something, there's no way to see what revisions have been made to an issue; can you elaborate?

I'm not clear how things would look and be navigated in this new PR scheme - but it sounds more complicated.

Exactly as described in EIP0: New EIPs are submitted as pull requests, and are discussed in the pull request. This seems simpler, to me, than starting off in an issue and then migrating to a file in the repository, and also allows amendments to EIPs to be discussed independently of the EIP itself.

[frozeman]

I am fine moving to PR's.

But ERCs are a clearly distinction from EipS, in the sense that ERC is more general and they can describe all the things like contract standards and issues about other ecosystem related software like web3.js

[gcolvin]

@Arachnid
Currently, if you go to https://github.com/ethereum/EIPs you find a list of EIPs. The number on the left of the EIP title takes you to the file for the EIP, and the history tab for that file takes you to the complete revision history. The Status on the right of the title is linked to the associated issue discussion. Everything is timestamped, user tagged, commit numbered.

So currently, EIPs start as de facto Issues that we call EIPs. Some issue discussions lead to a Draft EIP. That does require a PR. Sometimes there is further discussion attached to the PR. (But getting to that PR - or to a list of all PRs -is a pain.) Revisions to an EIP require reopening the PR, where more discussion can be attached.

I'm not sure what (if anything) we are proposing to change about this structure. The policy decisions seem to that for some reason we want to change the facto EIP number as it moves from being an Issue to a Draft? And that further technical discussion once the EIP is drafted be attached to the PR and not the original issue?

[Arachnid]

Currently, if you go to https://github.com/ethereum/EIPs you find a list of EIPs. The number on the left of the EIP title takes you to the file for the EIP, and the history tab for that file takes you to the complete revision history.

Right, but that's manually maintained and only covers the first 8 EIPs; it's not the process that people are using in practice at the moment, which is to post EIPs as issues.

So currently, EIPs start as de facto Issues that we call EIPs.

Right, and I think that's a mistake. The author (and only the author) of the issue can edit it at any time with no revision history, and it's not clear in some EIPs what the implemented version is. PRs work perfectly well for this purpose.

I'm not sure what (if anything) we are proposing to change about this structure.

I'm proposing, at least, that we actually follow the process outlined in EIP0. EIPs are submitted as pull requests, and reviewed in the PR. I don't see any reason for them to have a stage in their lifecycle uring which they are an issue tracker entry.

Changes are opened as new PRs with their own explanation. If we feel there's a need for a draft process before an EIP is officially accepted and given a number, we could follow the RFC convention and have 'draft-eip-some-descriptive-name.md' in the PreEIPs directory.

[gcolvin]

OK. It's a loose thing right now, but yes, as soon as an issue is posted we call it an EIP if it is a proposal to change Ethereum, and refer to it by issue number. I think it's understood that it's in a pre-draft stage, and may never get any farther. The advantage to this custom is that there is one main place for discussion that can be (manually) linked to later, and a number to remember it by. So I do find a use for this pre-draft stage. If we get rid of it we will need a replacement.

I'm not sure what you mean by "The author (and only the author) of the issue can edit it at any time with no revision history". Seems people comment on an issue - not revise it - and that is the history?

Once there is a Draft EIP there must a PR, and I'm fine with the process. I just find it very difficult to navigate the PR discussions in Github, especially if multiple revisions of an EIP require multiple PRs. So I think maintaining manual links on the front page will still be needed. But my preference would be for technical discussion of an EIP to continue under its issue number, (so the continuity of the discussion is not lost) and PR discussions be about problems with the merge (which are usually uninteresting once the merge succeeds).

[gcolvin]

@Arachnid An automatically generated web page as you mentioned above allays my concerns about fragmentation and navigability of the discussions on the PRs for EIP drafts and revisions.

For discussions leading up to a draft - EIP issues have been working well enough in our GitHub-centric world that I'd hate to just drop them unless we are sure we are moving to something better. I do see now what you mean about the issue author's privileges. I don't know that it's a problem pre-draft, but I'm surprised GitHub doesn't provide for administrator override. And I agree that it was wrong to start calling issues EIPs in the first place, but we do now, and Gitter helpfully abbreviates e.g. this issue's URL to #148.

You suggest that "If we feel there's a need for a draft process before an EIP is officially accepted and given a number, we could follow the RFC convention and have 'draft-eip-some-descriptive-name.md' in the PreEIPs directory." Which is fine, but you need to prepare a file and go through the PR process to even get something started there, whereas opening an issue is quick and easy. And for issues there usually is not yet a file to discussed. If there is, preEIPS might be a good place to put it.

[nicksavers]

The discussion on this seems to have continued in #183
Is there any reason to keep this issue open?

[Souptacular]

@nicksavers After the new EIP rules/proceses go into affect I am cleaning up the issues and closing ones that are done.

[Souptacular]

Closing per #183