[PROPOSAL] Standardized Process for New Repository Creation in OpenSearch Software Foundation

[peterzhuamazon]

[PROPOSAL]

Standardized Process for New Repository Creation in OpenSearch Software Foundation

---

Background

As part of the transition from the OpenSearch project to the OpenSearch Software Foundation, some processes, including repository creation, need to be updated. Previously, the Open Source Project Office (OSPO) team at Amazon reviewed and approved repository creation requests. Now that we are part of the Linux Foundation, we need a similar process to ensure transparency, security, and compliance with foundation policies while maintaining consistency across all repository creations.

Proposed Process

Although repositories on platforms like GitHub and DockerHub serve different purposes, they would benefit from a standardized process to ensure consistency and compliance. The proposed process includes:

1. Proposal Submission: Community members submit a proposal following a standardized checklist.
2. IP Review: If the Technical Steering Committee (TSC) raises concerns on intellectual property rights, the project may undergo a formal review by legal experts.
3. Code Review: Existing source code (if any) is reviewed for proper licensing.
4. TSC Review: The Technical Steering Committee evaluates the proposal, listens to the proposal during the meeting. A final decision is made based on the feedbacks / reviews
5. Linux Foundation Ticket: A request is submitted to the Linux Foundation to create the repository.
6. Automated Setups: Automation is triggered to configure repository settings, including secrets management, default templates, license verification, CVE scanning, and other necessary tasks.

Proposed Steps

1. Proposal Submission

   • Steps:
     • Review the OpenSearch Software Foundation Charter
     • Open an issue with <template> in .github repo (pending template creation)
     • Pending feedbacks and comments from the community
   • Questions:
     • Who is responsible for maintaining and updating the checklist?
     • Potential Owners: TSC

2. IP Review

   • Steps:
     • If any member of the TSC raises concern on intellectual property rights, a legal expert / open source evangelist will do a review on the IP
   • Questions:
     • What criteria should be used for the IP review?
     • Who will conduct the IP review?
     • Potential Owners: Linux Foundation Lawyer, TSC Legal Representative

3. Code Review

   • Steps:
     • Make your source code available to public, attach the url to the proposal issue above
     • Follow a checklist to prepare your source code to meet certain criteria (pending checklist creation)
       • License Header
       • Copyright message
       • The code and library must be compatible with Apache License v2.
   • Questions:
     • Who will perform the code review?
     • What tools or automation can assist in code review for licensing compliance?
     • Potential Owners: Maintainers, Legal Team, Security Review Team

4. TSC Review

   • Steps:
     • Once IP self-certification / review and code review is completed, send an email to <@> with the proposal link, and asked to be reviewed by TSC
     • In order to be approved, at least three positive (+1) TSC members’ votes are necessary, and no vetoes (-1) after a one week period.
     • TSC members can meet and discuss if needed.
     • A decision was made based on the vote and get recorded in the proposal issue above
       • (inclined / declined / revision required for another review?)
     • A PR can be created to add the new repository into a list, approved by TSC members
   • Questions:
     • What should the TSC consider before approving a repository?
     • How will the TSC review process be documented and tracked?
     • What is the expected timeline for review and approval?
     • Potential Owners: TSC

5. Linux Foundation Ticket

   • Steps:
     • A ticket with Linux Foundation will be created in help desk on requesting a new repository
     • The proposal + decision will be attached in the ticket
     • Linux Foundation deliver the new repository in set amount of days
   • Questions:
     • Who is responsible for submitting the ticket?
     • Potential Owners: TSC, OpenSearch Project Admins

6. Automated Setup

   • Steps:
     • Once the repo is created, a set of automations will be run against the repo
     • Add templates related to OpenSearch project
     • Add tools such as CVE scanning, license checker, backport secrets
     • Add branch protection rules, set initial maintainers, etc.
   • Questions:
     • Who maintains the automation and ensures they remain up to date?
     • Potential Owners: OpenSearch Project Admins

Conclusion

This process ensures transparency, security, and alignment with foundation charter while standardizing repository creation in OpenSearch Software Foundation. It shows clear steps, defined ownership, and automation to help the community to contribute effectively. We should move forward to implement this process collaboratively.

[peterzhuamazon]

Hi @reta @dblock @sam-herman @anastead @Pallavi-AWS @getsaurabh02 @jmertic @tykeal,

Let me know your thoughts on this.

Thanks.

[anastead]

Thanks Peter for tagging me. Do we really need TSC to approve every repo creation? I was wondering if we can pick a special interest group (SIG) who are release and repo owners and nominate a few maintainers including a TSC person (if needed) who can make these calls? tagging @hyandell for some ideas on this as well .
I was talking to Davanum Srinivas who is cncf tsc and he referred the following:
TSC owns and defines the process. then the TSC delegates its power to a select group of folks who work the process in a day-to-day fashion. (TSC can still step in an say no, but they don't need to be actively engaged).
For example in Kubernetes:
policy/process - https://github.com/kubernetes/community/blob/master/github-management/org-owners-guide.md
managers of github repos - https://github.com/kubernetes/community/blob/master/github-management/README.md#github-administration-team
folks can create an issue in https://github.com/kubernetes/org/issues to add/delete a repo
10:48
another example slightly different .. opencontainers org use a template like this one we recently created a new repo called cgroups
started as an issue opencontainers/tob#144
once it merged https://github.com/opencontainers/tob/blob/main/proposals/cgroups.md
some admins of github org created the repo and added the specified maintainers

[Pallavi-AWS]

I was wondering if we can pick a special interest group (SIG) who are release and repo owners and nominate a few maintainers including a TSC person (if needed) who can make these calls?

Agree with formation of a repo approver group composed of a couple of representatives from release/infra, a set of maintainers representing core, top 10 repos, a TSC representative and a legal representative if initial review gets flagged by the repo approver group. We need to work proactively to avoid the proliferation of repos that eventually get abandoned.

[peterzhuamazon]

Yes, we do need to take a look whether TSC Review would be the bottleneck depending on the number of repo creation requests.

In nomination process, each repo can vote within their own group, so not rely on the TSC to make decision. While repo creation would need SME to review Project / IP / Licensing / Code and make a decision.

Thanks.

[tykeal]

LF Release Engineering will go with whatever process is approved. Either TSC approval required or some other TSC delegated SIG.

Step 6 can be fixed up some by using a template repository as long as we're talking green-field code repositories that way extra work doesn't need to be done if one is created and maintained.