Graduation from conda-incubator to conda could be more detailed

[travishathaway]

What's the idea?

I was recently reading through the governance document to figure out exactly how projects move from conda-incubator to conda. Even after reading these two sections:

1. Incubation
2. Project Team Details

In order to make the process of graduating from incubation to conda a little more clear, I propose adding a special section that defines this process in more of a linear way and perhaps even uses examples to make it more clear.

Additionally, we could even add a check list temple issue for this repository that incubation projects could use when making the jump to "conda". This template could look like the ones we have for releases:

https://github.com/conda/infra/blob/main/.github/sync/RELEASE.md#1-open-the-release-issue

[beckermr]

This sounds fine. What are the things you found confusing?

[tnabtaf]

@travishathaway Thanks for looking at this. I am all for making things clearer.

[travishathaway]

@beckermr Here's a brief list:

• What requirements does the code itself need to meet before heading to conda? (testing infrastructure, linting, copyrights, etc.) Is this just determined case-by-case?
• What happens if we need to reassemble the project team? (i.e. the original incubator maintainers are unwilling or unable to commit to the project being graduated, yet there is a need/desire for it to be)
• Are there any guarantees that the project team needs to make when being graduated? (thinking here about responding to feature requests and bug reports in a timely manner; seems like there would be higher standard for actual "conda" projects)

Some of this may be out of scope for this document, but they seem like fair things to address.

[beckermr]

So here is what the docs say

At some point, many projects will want to be included in the main conda GitHub (or otherwise) organization. Moving a project into this organization can be done with a super-majority vote from the Steering Council. There are no strict criteria for when a project is ready, stable, or viable for this step. Rather, Steering Council members are entrusted to use their objective best judgment and common sense when making this determination. Adherence to conda specifications is a particularly important aspect of the decision to include a project in the main conda organization. The membership of the initial Project Team should be included in the vote information. There is not requirement for a project to incubate before a vote of this nature can be called. This kind of vote applies only to software projects. Specifications are covered separately.

They address your second point in that the project team is specified with the vote.

They also explicitly exclude anything related to the first or third points.

We cannot add details or requirements like this without a vote of the steering council.

[beckermr]

So the only requirement is that the vote passes and implicitly that the project adheres to our code of conduct, obeys laws/licensing stuff, obeys our governance, etc.