Reading the various opinions concerning the subject gives me the impression that many of the differences are driven by semantic connotations. As I see it, these semantic connotations revolve around the concept of process and the guarantees –or non-guarantees– of success that a particular project, action, or initiative can provide.
I won’t succumb to the temptation of copy-pasting the definition of process here. I’m sure if we stop for a minute to think about what a “process” is, we can all quickly come to a shared understanding or common ground.
We can say that having a process in place does not guarantee a solution of continuity, just as not having it does not guarantee the opposite, as well mentioned by @bitcoincashautist.
Even so, processes are proposed, discussed, and implemented in an exorbitant number of initiatives, whether corporate or FOSS –I don’t see these two as mutually exclusive, but just for the sake of the example– worldwide. The literature takes good care of the benefits of having processes with a certain degree of standardization. Although processes are not the philosopher’s stone by themselves, they can pave the way between the launch of an initiative and the goal to be achieved.
Once the aspect of around process and its benefits are solved, I suppose we fall into the realms of old human nature. In the end, we are all little machines working under the precepts of intentions, incentives, and rewards. Perhaps we should ask ourselves again about our intentions regarding this initiative, our incentives, and what rewards we hope to obtain, either for ourselves or for the Bitcoin Cash community.
I’m very much in line with the idea that the process is here to help spread ideas, to guide analysis and discussions. But for me, this needs to happen in a broad sense, not limited to a single or specific aspect of the network’s development. Of course, this is when the component of intentions appears again, and that is just right because different intentions can work in towards greater diversity.
Different aspects of the network may require more or less standardized processes; some, by their very nature, may require a greater or lesser degree of formality, some may allow a greater degree of flexibility. Different actors may want to focus on one aspect or another. But that doesn’t make the aspect in need for higher formality more important than others. It merely makes it particular and different, with value in itself. As well as other aspects will have their value.
It’s essential to me to maintain the sufficient and necessary structures to offer this possibility, to provide the basis for opening new fronts and not closing them. Luckily, to do so in Bitcoin Cash is relatively easy –at least easier than others 
. Due to our ecosystem’s decentralized nature, actors have the fundamental right of free initiative. Although this free initiative has no means to be prohibited, it can sometimes be relegated or not sufficiently encouraged. And that’s the part that worries me.
On top of that, sometimes it gives me the impression that we are trying to re-invent the wheel. We have a system that works quite well, it’s not perfect, but it served the purposes of Bitcoin for all these years, the system of Bitcoin Improvement Proposals (BIPs).
The system is not original from Bitcoin, but it is based on Python Enhancements Proposal (PEPs). Many of the formatting ideas, as well as the Type and Status classifications, come from Python. Time later, BIP 0123 brought the Layers specification, adding even more value.
In my opinion, these BIPs’ three components: Type, Layers, and Status, work amazingly well. They allow the necessary operability, granularity, and flexibility for the development of Bitcoin Cash and improvement proposals in an inclusive, comprehensive way.
Surprisingly enough, this system considers the presentation of processes, information, and aspects related to Bitcoin Cash development that are not necessarily part of what we understand as Consensus itself. And that, I think, adds an interesting dimension to it. Does that diminish the importance of Consensus aspects? It does not, not at all. In fact, I believe that Consensus as an abstract entity can benefit from the diversity that BIPs’ classification proposes.
If something is working correctly, why change it?
Good question.
Is there room for improvement?
Yes, there surely is, but that doesn’t mean we have to invent a whole new system.
In short, I propose to maintain BIPs format and classification (Type, Layer, and Status, with their corresponding classes) for CHIPs. Let’s identify the ideas and practices around BIPs structure that need to be improved and propose the changes based on that, not changing just for the sake of change.
I like to think that Bitcoin Cash is the closest Bitcoin implementation to Satoshi Nakamoto’s project. The shared history is undeniable. And this brings up some perhaps uncomfortable questions…
Can BIPs be considered as CHIPs??
At least until the moment of Bitcoin Cash inception, I would say yes. Perhaps it’s not the most politically correct answer. But isn’t our protocol in good part governed by what those BIPs express? With that perspective, those BIPs can be considered a subset of CHIPs.
Should we rename pre Bitcoin Cash BIPs as CHIPs on our servers/platforms?
Please do not. I assume the community would like to keep track of history as it is.
Hold on, if you say that every BIP (before Bitcoin Cash) can be considered a CHIP, why bring the CHIP name to happen?
There are undeniable logical reasons for that. At the end of the day, we are Bitcoin Cash. Continuing to use the BIP name for current Bitcoin Cash development would only add confusion, despite the improvements we would like to apply to BIPs concept.
What should we do with the BIPs post Bitcoin Cash inception? Or how should we consider them?
I do not know. Probably we should ask ourselves if there is any value in them that can be applied to Bitcoin Cash. I’m going to let people with the required experience answer that.
And what do we do with all the specific Bitcoin Cash development of these last four years?
To the responsible actors of these developments, I would recommend creating corresponding CHIPs, with the original dates for the proper historical record and the Bitcoin Cash community’s benefit.
Should CHIPs have their own parallel numbering or continue from the last BIP number (until the moment of Bitcoin Cash inception)?
I do not know.
Should we make format and classification (Type, Layer, Status) be mandatory for CHIPs?
Given Bitcoin Cash decentralized and open-source feature, I don’t think there is a way to impose it. And if it exists, I don’t think imposition would be the best option either. But I do think it should be explicitly recommended to improvements’ proponents, at least that’s my opinion.
Let’s write together the CHIP 0001 (if necessary) with all the recommendations the case requires, including formats and associated processes. Or let’s include associated processes in other CHIPs if that makes more sense. In any case, it is clear that people are working on it already. This work will probably require some time and several interactions between different actors but it should not impede the flow of incoming CHIPs reaching Bitcoin Cash. There is always time for formatting and minor adjustments, but that should not prevent the spread and discussion of ideas.
I base my proposal on what I believe will translate into stakeholders’ –users, developers, miners–greater participation in Bitcoin Cash development and continuous improvement. I am convinced these are great times for Bitcoin Cash.
So what to do?
