About “a CHIP is not supposed to be the process”:
I am in fact focusing this proposal around a process, because I think it is the most important part. The formatting is secondary to the process. Recommending a decisionmaking process that has clear milestones, outcomes and expected information along the way can prevent chaos, and the formatting I attached is just things I expect out of a persuasive proposal in that process. People can and likely will add their own spice to the format.
But my point is, formatting guidelines by themselves don’t do very much. A “clean” formatting template might be convenient (see also !1, which I need to get to), but they are not the meat of the document either way.
If someone wants to make amends to the formatting, I’m quite open to them! But if the request is instead “let’s not recommend a process here at all”, then that removes the primary reason, in my opinion, of this whole effort. I’m aware that different people have different understanding about what this specific thing named “CHIP” should or should not be, and I appreciate that; but I’m going to focus on what seems (to me) to be the most important thing out of this endeavor. If the criticism is that it really should be called something else, I’m open to suggestions. Cash Improvement Processes (CHIPRs)?
About “operational CHIPs” , or CHIPs on things that are not consensus (or pseudo-consensus, like mempool-policy and network protocol):
Don’t get me wrong, I’m not against them existing, or being discussed, or using this specific format for discussion! I think I need to get that out of the way, so that it’s not misunderstood down the line.
With that said, I tried to focus my effort around consensus/pseudo-consensus proposals because:
-
They are the most consequential, where failure to reach wide agreement can/will actually lead to network splits.
-
Conveniently they are also the most amenable to clear milestones and outcomes in most cases without costly elections. Clear information at each step and unambiguous outcomes are necessary, in my opinion, for a process to be meaningful.
Consider a “marketing CHIP” that proposes “Change the official BCH color to purple”. One can probably list lots of information in a similar format, but end of the day, it’ll be exceptionally difficult to have a clear outcome. If it cannot have a clear outcome, then it doesn’t need the relatively elaborate process I’m proposing here.
Q: But wait, I just want to use this format to write a proposal since I like it! I don’t care about the process!
A: You can already do that! 
Q: Alright, yes I can. But if you don’t designate them as an “explicitly recognized class” of CHIPs, wouldn’t the repositories just ignore them, hence my proposal won’t get the exposure it needs?
A: I don’t have any objection about the inevitable repositories that crop up listing any category they want - imo it should be up to each repository. In fact, since having more things listed tend to bring more traffic than less things, I expect many of them to do so!
I think end of the day, the difference is really in emphasis: My primary goal is an orderly process of change that minimizes possibility of split, chaos, dictatorship, and ossification, so the outcome is that my document is oriented around consensus changes and the process, instead of “resolving differences in general” and formatting guidelines. The good news, of course, is that people with different understandings can easily improve in their own ways without even conflicting… unless it’s about naming, I guess. 
So what to do?