Withdraw `conda/conda`-specific CEPs (2-10)

[jaimergp]

Our CEP process has matured in efficiency, popularity and scope. In hindsight, CEPs 2 to 11 should have not been ecosystem wide decisions (governed by @conda/conda-maintainers), but conda/conda specific ones (governed by @conda/conda-maintainers). I propose we withdraw those CEPs and instead adopt them as CCEPs (conda/conda enhancement proposals, or conda client enhancement proposals, whatever).

[jezdez]

As the person who has authored many of the CEPs mentioned and has worked tirelessly to make the CEP process happen in the first place, I strongly disagree. In fact, I'm sad to see this, since you're proposing a separation of specs where collection is useful.

As an example of a healthy diverse specification body, look at PEPs for example, they do not only refer to CPython internals, but handle all kinds of other technical changes or social aspects.

CEP 1 leaves the scope of the CEPs open by design and only refers to the "conda project", as the general purpose of the CEP process. Granted, we can update the terminology used in CEP 1 to make sure it accounts for all conda-related projects. Ultimately, the CEP process exists to streamline consensus finding in a multi-stakeholder ecosystem, and it does not only apply to either conda/conda or, say, only specifications.

By the way, I would hope that projects like mamba or rattler/pixi would also propose CEPs, for their respective projects if it helps their projects.

TLDR; Your proposal tries to redefine the CEP process without additional gain. I posit that a withdrawal of the CEPs mentioned will ultimately just means less coordination and more project silos.

I strongly oppose this direction, since I believe that was at the core of the previous failure to organize a conda open-source community.

[jaimergp]

CEP 1 leaves the scope of the CEPs open by design and only refers to the "conda project", as the general purpose of the CEP process.

Even if we try to be really open about what "conda project" means, it is still referring to conda/conda as evidenced by this part pointing to its issue tracker:

ceps/cep-0001.md

Lines 38 to 41 in 4f4ac75

	The CEP process begins with an idea for a change in how the conda project
	works. These changes can be technical or address the social aspects of the
	project. Small changes often do not need a CEP and can be discussed on the
	[conda issue tracker](https://github.com/conda/conda/issues).

At no point it mentions the "ecosystem", but more like the "project" and the "project community", which puts conda/conda at the center of the process. Or at least that's how I read it.

What I was trying to mean, and possibly failed at explaining, was that the CEP process has evolved from a conda/conda centric process into a "matter that concerns the whole ecosystem" and hence requires consultation to the steering council.

In hindsight, the steering council and the conda maintainers team (formerly "core", as referred in CEP 1) might have been used interchangeably in the original intent and led to confusion.

I am not saying that CEPs 2-10 have no value and I really appreciate the efforts you and others have made to get us all here. I have authored a few CEPs myself and I think it's a great vehicle to strengthen our ecosystem.

In a nutshell, my previous message could have been:

I observed that CEPs 2-10 and conda/conda specific, and that from CEP 11 onwards, we have used this process for ecosystem-wide standardization. I perceive this as a change of scope. How do you feel about withdrawing the conda/conda specific ones to reflect this change?

BUT I do see this point you bring up:

Granted, we can update the terminology used in CEP 1 to make sure it accounts for all conda-related projects. Ultimately, the CEP process exists to streamline consensus finding in a multi-stakeholder ecosystem, and it does not only apply to either conda/conda or, say, only specifications.

I think that's a great idea and we should absolutely update CEP 1 to make this intent clear.

In fact, I'm sad to see this, since you're proposing a separation of specs where collection is useful.

Now I'm sad too! I'm so sorry I made you feel this way with my message. I hope I clarified what I meant with the paragraphs above. I'll be happy to further detail my intent if necessary, but please accept my apologies and know that my only intention here was to strengthen the purpose of CEPs, and not the opposite. I am now excited about what we can do with some CEP 1 edits.