TLDR, this provide with this ECIP repository a working ECIP process derived from BIP-2 (the current BIP process being used).
Right now we don't have a defined ECIP process. The informal one being used EIP-1 is derived from BIP-1. This has, in the Bitcoin community, long been replaced by BIP-2, a revised BIP process. I propose we modify BIP-2 and make it suit our needs. Immediate advantages it will provide:
It defines the concept ECIP editors and their responsibilities. This allows us to get clear ideas on when a new ECIP should be merged.
It defines how new ECIP numbers are allocated.
It uses Wiki to store long and detailed comments for ECIPs, which allows reader to find them more easily.
There's one additional state for ECIPs -- from Draft, it can go to Proposed before it reaches Final/Active.
This is basically the same as #49 proposed by @dulanov. Differences to BIP-2 are:
Recommended license: we seem to mainly use Apache-2, so that's moved to one of the recommended license.
Mailing list reference: we don't use mailing list for Ethereum Classic, so those sections are removed.
Discussion about hard/soft forks: those are rather sensitive so they are removed from this proposal. ECIPs related to consensus soft/hard fork should decide their own best way to conduct network soft/hard forks.
@sjmackenzie You might also like this as many parts of this are quite similar to COSS. 😃
(Rendered)
TLDR, this provide with this ECIP repository a working ECIP process derived from BIP-2 (the current BIP process being used).
Right now we don't have a defined ECIP process. The informal one being used EIP-1 is derived from BIP-1. This has, in the Bitcoin community, long been replaced by BIP-2, a revised BIP process. I propose we modify BIP-2 and make it suit our needs. Immediate advantages it will provide:
This is basically the same as #49 proposed by @dulanov. Differences to BIP-2 are:
@sjmackenzie You might also like this as many parts of this are quite similar to COSS. 😃