[PROPOSAL] Document a clear(er) bar/process for moving repos into opensearch-project

[dblock]

What/Why

What are you proposing?

In opensearch-project/OpenSearch#11326 we are discussing moving a plugin into the OpenSearch distribution. We need some clearer guidelines on what it takes to

1. Move a repo into the opensearch-project organization. We have https://github.com/opensearch-project/.github/blob/main/ADMINS.md#new-repos, but it's a little light.
2. Move a plugin into the opensearch-project organization.
3. Include a plugin in the default OpenSearch distribution.

What users have asked for this feature?

See opensearch-project/OpenSearch#11326.

What problems are you trying to solve?

Point contributors to clear guidelines.

What is the developer experience going to be?

Developers will be able to follow a clear process of moving a repo into the org.

Are there any security considerations?

Every new repo in opensearch-project will need to pay a lot of attention to security processes, we need to document what those are.

Any remaining open questions?

We have done this in the past, e.g. opensearch-project/opensearch-plugin-template-java#4, .and https://github.com/opensearch-project/opensearch-learning-to-rank-base.

[dblock]

cc: @rursprung @AmiStrn

[AmiStrn]

Thanks for starting the conversation @dblock

I suggest a back tracking method to deduce a process.

Assuming a plugin is in the default distribution is a testament to the popularity of the plugin and the trust in the stability and possible longevity of it within the project.

If it's not in the default distribution but in the project then all the above applies except the popularity of use.

A repo that is not a plugin wont be in the default distribution in most cases.
It is however, a trusted auxiliary tool and there is a need for an official one to focus community efforts.

Does this resonate?

If so, then:

1. a minimum of (2?) dedicated maintainers that agree to take the responsibility of maintaining it in the future.
2. consensus from the core maintainers that the repo should be in the project
3. engineering reasons to be part of the default distribution
4. pass some security audit
5. pass some performance benchmark tests
6. pass license/legal requirements

(That is off the top of my head)