New "cncf-tags" GitHub org to host TAG specific projects

[nikhita]

There have been requests from TAG Runtime and TAG App Delivery to have someplace where the TAGs can host repos they are working on. These repos involve code but aren't projects that can be applied to the CNCF.

For example:

• podtato-head is a demo app for TAG App Delivery
• TAG Runtime would like a vendor-neutral location to host the CDI spec.

Proposal

Create a new GitHub org called cncf-tags to serve as a home for TAG-sponsored projects and tools. This org is intended to provide a vendor-neutral place for TAGs to collaborate on projects endorsed by and actively worked on by members of a TAG.

This is similar to the https://github.com/kubernetes-sigs model. Repos will be searchable per TAG through repo labels. For instance, these are all the repos for sig-cluster-lifecycle - https://github.com/topics/k8s-sig-cluster-lifecycle.

Approval to create a new repo in cncf-tags

• Must be approved by the TOC liaisons for the respective TAG.
• Must be approved by at least one of the TAG leads or any process spelled out in a TAG's charter.

A publicly linkable written decision should be available for all approvals.

Access for each repo

• TOC liaisons for the respective TAG + TAG leads should have admin access.
• TAG leads may grant additional priviliges (write/admin access) to other TAG members. A publicly linkable written decision should be available for granting such access.
• Repository access will be maintained through .github/settings.yaml for now and later migrated over to CLOWarden (the current process for the cncf org) once multi-org support is implemented in CLOWarden (https://github.com/cncf/clowarden/issues/43).

Archiving a repo

TAG repos may be archived if they are deemed inactive. Inactive repos are those that meet any of the following criteria:

• There are no longer any active maintainers for the project and no replacements can be found.
• All PRs or Issues have gone un-addressed for longer than six months.
• There have been no new commits or other changes in more than a year.
• The contents have been folded into another actively maintained project.

Approval for archiving a repo

Requires approval from:

1. At least one TOC liaison for the respective TAG
2. At least one TAG lead

Mandatory files

Each repo, at minium, should have the following files:

• LICENSE
• code-of-conduct.md
• README.md
• CONTRIBUTING.md
• SECURITY.md

https://github.com/kubernetes/kubernetes-template-project can referred to for inspiration.

If there are no blocking comments, I will open a PR to document and codify the above policies.

[nikhita]

cc @AloisReitbauer @Jenniferstrej @hongchaodeng @AlexsJones @thschue @joshgav TAG App Delivery

cc @raravena80 @helayoty @quinton-hoole @k82cn @kad TAG Runtime

@cncf/cncf-toc please review and leave comments or +1s.

[nikhita]

cc @RobertKielty for any comments on using ~Sheriff~ CLOWarden for the new org

[kad]

big +1 from CDI WG. Getting CDI spec under CNCF umbrella will be huge help for us, and for all projects that are nowadays depends on that repository.

[quinton-hoole]

Sounds very sensible. I'd add an explicit process for deprecation/archiving, to prevent an accumulation of abandoned repos.

[nikhita]

I'd add an explicit process for deprecation/archiving, to prevent an accumulation of abandoned repos.

Good point! I've updated the issue body to add more details around archiving a repo.

---

I see explicit +1s from TAG Runtime and some TOC members. Will wait for +1s from TAG App Delivery before opening a PR to codify this process.

[nikhita]

@lukaszgryglicki would it be possible to add this github org to devstats?

[leonardpahlke]

I like the proposal 👍 +1, in TAG ENV, a new working group is emerging that will likely develop some small tools for creating sustainability reports for CNCF projects. Good to see this being formalized :)

[RobertKielty]

@nikhita thank you for tagging me on this issue; your doing so has generated a design discussion on CLOWarden internally and has helped move development of this tool forward. Thank you again!

We are fleshing out a new feature request to enhance CLOWarden to handle this use case, let me explain with a bit of background on CLOWarden.

CLOWarden

CLOWarden is drop-in replacement for Sheriff; CLOWarden has been commissioned by the CNCF and is undergoing active development at this time.

A first release of CLOWarden has been deployed to manage the main CNCF GitHub Org and is being used successfully.

CLOWarden provides an access control service for GitHub repos in a single GitHub Org.

We can grant or deny GitHub Profiles access to GitHub repos in the controlled GitHub org. (We can also define teams and sub-teams to make managing larger groups easier)

All of this is done using Pull Requests to change the access rules on cncf/people/config.yaml.

Today, we use it to control access to GitHub repos, and there are plans to expand CLOWarden to control access to resources on other services.

So given that background let's look at the use case that you have presented here.

Multi org management The first release of CLOWarden is designed so that one deployed instance manages a single GitHub Org.

In requesting an access control service to a new GitHub Org we now have to consider how to handle that and will flesh out that requirement on this issue https://github.com/cncf/clowarden/issues/43

You can track development over on that issue.

It would be useful (but not necessary) to get an estimate of how many repos you expect to have setup here. If it is a small number of repos we can allow you to use access control rules in .github/settings.yml files on target repos to get you started. ** Then when the CLOWarden instance is mult-org capable we could easily roll out CLOWarden to accommodate and centralize access managment.

** (Normally, when CLOWarden is deployed and in use we discourage the use of repo-local settings.yml files in favor of the centralized config file location.)

https://github.com/cncf/clowarden

[nikhita]

@RobertKielty thank you so much for the detailed response!

It would be useful (but not necessary) to get an estimate of how many repos you expect to have setup here. If it is a small number of repos we can allow you to use access control rules in .github/settings.yml files on target repos to get you started.

At this point, we mainly expect repos that will be migrated from https://github.com/podtato-head and https://github.com/container-orchestrated-devices. Considering any additional repos that might be added as a part of TAG ENV (https://github.com/cncf/toc/issues/1098#issuecomment-1609862188), I'd say we'd have ~8 repos (give or take) to start with.

IMO it should be ok to control access via .github/settings.yaml for now and we can migrate over to CLOWarden later.

Then when the CLOWarden instance is mult-org capable we could easily roll out CLOWarden to accommodate and centralize access managment.

@RobertKielty is there an approximate timeline for when we can expect CLOWarden to have multi-org support? Will definitely follow along https://github.com/cncf/clowarden/issues/43 to keep track of latest updates 👍

[AlexsJones]

This makes a lot of sense, thank you for getting the ball rolling on it - I am in full support.

[nikhita]

Given that we have +1s from several TAGs and TOC members, I have created https://github.com/cncf/toc/pull/1100 to document this policy. PTAL.

[nikhita]

Reopening until the org has been created.

The CNCF ServiceDesk ticket is now assigned to @RobertKielty and they are working to set up the new org.

[RobertKielty]

Looking at this now

[RobertKielty]

@nikhita I've created https://github.com/cncf-tags

I've invited you, @amye and @jeefy to join as owners. I can see you accepted the invite.

@tegioz @cynthia-sg cncf-tags is the org that we would like to use for UAT of upcoming multi-org capabilities of CLOWarden when those features are available for use.

Extending CLOWarden so that it can manage multiple GitHub Orgs is partially complete and there remains some work to be done to expose that functionality via the web front-end.

For now, we can manually control access using the GitHub UI/settings.yaml in individual repos but when CLOWarden is multi-org capable we will migrate over to using CLOWarden.

[nikhita]

@nikhita I've created https://github.com/cncf-tags

I've invited you, @amye and @jeefy to join as owners. I can see you accepted the invite.

Thanks, @RobertKielty!

For now, we can manually control access using the GitHub UI/settings.yaml in individual repos but when CLOWarden is multi-org capable we will migrate over to using CLOWarden.

@RobertKielty just to confirm, does this mean that repos can now be migrated over/added to the cncf-tags GitHub org?

[RobertKielty]

@nikhita Yes, you can start migrating repos.

Just let people know that in the future we will move to using CLOWarden to manage access like we do on the main cncf org.

[nikhita]

@RobertKielty awesome, thanks!

For anyone interested to create a repo in cncf-tags, please follow the process here - https://github.com/cncf/toc/blob/main/tags/cncf-tags-github-org.md#creating-a-new-repo.