Thoughts on EIPs and interoperability

Process Improvement
1

@boris,
Here is the short collection of my thoughts on EIP process for that sad case if I am not able to take part personally. Would be great if it could be discussed in “EIPs and Interoperability” session.

Thoughts are:

  1. Ethereum is not only the Core any more. Now it is the whole ecosystem around it.
    Thus, it makes sense to extend the goal of the EIP process from serving the Core Development to serve the whole ecosystem.

  2. It is not sufficient to tag all not-Core EIPs as ERC - they are too different in their meaning and their processing.

  3. It is not sufficient to include only CoreDevs into the EIP process . Application dev communities should be involved into the EIP workflow too.

  4. Call for Action (CfA): It should be possible to call community attention to some global problem without proposing an improvement. CfA will become an EIP if anybody proposes a solution.

  5. Editors should classify incoming EIP proposals as one of additional kinds of:

    1. CfA - Call for Action (see above)
    2. Design Pattern - nice to have, voluntary to use, mutable in the future, no global consensus needed, no danger of hard fork.
    3. Standards (like ERC20): once adopted - then immutable, comprehensive review needed, no global consensus needed, no danger of hard fork, but danger of multiple different standards.
    4. other kinds of EIP?

  6. EIPs should be routed (signaled) between different communities in order to collect comprehensive reviews.

  7. There should be simple standardized review states like (OK / INWORK / REJECTED ) to signal the review result between Communities and Editors.

More implementation details you will find in Decentralizing EIP Workflow Proposal. I am currently working on software implementation of it, so I am glad to discuss all the details in depth and interested on any specification input.

1 Like