Problem: ECIP process not well defined

[sjmackenzie]

Problem: The ECIP process suffers from these issues

• Not easy to fork and merge specifications
• naming convention is obtuse e.g. what meaning can we extract from ECIP-2016 vs 12/MONPOL 12/MONPOL is a version of the MONetary POLicy. Making it very easy to discuss on forums multiple different potential */MONPOL specifications i.e. 12/MONPOL vs 14/MONPOL.
• Not easy to collaborate with early stage ECIP (in the previous process) as they were defined in unmerged Pull Requests and Issues.
• We need an easy to use, fast moving specifications repository for SputnikVM and other projects.

Solution: make use of this 2/COSS to manage the ECIP process

[sorpaas]

(@sjmackenzie I would suggest you to break down this PR to some smaller ones (containing C4 and COSS only) if you really want to do something with it.)

I'm involved in C4 right now and we currently apply this to SputnikVM, so I'm probably biased, but I would like to add a few data points to this issue, and encourage some discussions on this issue if you're interested.

For people who are not familiar with this, this basically applies optimistic merging (a.k.a. C4) to ECIPs. The author has an amount of experiences of working in C4 (Fractalide and ZeroMQ). However, we didn't have a good experience in using it right now. From my experience, for this unmodified version of C4 to work, the community needs either:

• Core developers have ways to reach consensus in prior or using other ways to reach consensus than using Github issues and PR.
• The community has a strong community leader, and that leader has a large saying on most aspects of the community.

Our community doesn't have those properties, and we've indeed met several incidents using this for SputnikVM and the projects related:

• We tried to apply C4 in RFC, in which we are planning to create a complete EVM specification (the Yellow Paper has a few obstacles right now that prevents it from being a good specification for EVM implementators). We've had incidents of merge and revert that results in confusion of other maintainers and the contributor. This has since resulted in a fork of RFC that aims to provide improvements to the current C4 and COSS process.
• If a maintainer or contributor has too strong opinions of how other people should code or commit in style, then we have patch wars (which is not so uncommon if optimistic merging is applied too strictly). C4 does not mention how a patch war should be handled.
• People who are not familiar with the concept of C4 can easily be frightened away.
• C4 does not have a way to handle PRs that provide new features. See this discussion from the Odoo community.
• C4 is a derivation of Github's Fork and Pull Model. Github has since involved to provide better process (for example, right now a maintainer can directly push commit to a PR in certain situations), but C4 has not adopted to them yet.

SputnikVM right now uses 20-C4, an experimental improved version of C4 that aims to solve those problems. But right now we haven't reached anywhere yet. So I would suggest we have some more discussions first here -- what problem does C4 solve for ECIPs? How should C4 be modified to suit ECIPs' need?

[realcodywburns]

I think the consensus oriented system would be a much needed improvement over the current system

[splix]

I also want to avoid formalising the process, in my opinion C4+COSS isn't required there. Also I'd prefer existing naming convention with just number + title (ECIP-1010 Delay Difficulty Bomb Explosion). Because it's simpler, there are no problem with it currently and it's standard convention for most of other cryptocurrencies.