Proposal: New GitHub *organization* as part of OpenSSF: something like repository-service-tuf

[david-a-wheeler]

Background: VMware is offering to contribute "rstuf" (repository-service-tuf) to the OpenSSF - and we thank them! That offer will be need to be decided on using the OpenSSF's usual processes, and then handled usual processes.

However - and this is the wrinkle - they believe this set of projects would be better added as a separate GitHub organization,. instead of being under "ossf". It'd be something like "repository-service-tuf" or similar. I don't have their full rationale, but I'm sure they'll share it. That said, this is an unusual request, and I wanted to see if the TAC had any thoughts or more general principles about other GitHub organizations.

The OpenSSF has created or used other GitHub organizations before beyond ossf, e.g.:

• Sigstore
• Core Infrastructure Initiative

However, I also think this kind of request is something that should be granted sparingly and brought to the TAC early (as I'm doing here). I think it should be done sparingly because it makes it harder to use analytics (e.g., LF Analytics applies separately to separate GitHub organizations), audit permissions, discovery, etc. But those are arguments for doing it sparingly, not necessarily to never do it.

I presume that the TAC would specifically want to approve such creation. Is that correct? Presuming taht, are there specific conditions the TAC would like to see/impose for creating a special organization on GitHub? In particular, does the TAC want to set any particular policy on when other organizations may be used/created? I think the projects will provide their justifications, but if the TAC has any guidelines I think they want to hear them.

We're just anticipating a request & trying to get it resolved.

Thanks!

[david-a-wheeler]

Here are more details from the RSTUF project on why they think a separate organization would make sense in this case.

Fundamentally, the RSTUF project has multiple components/repositories, repository-service-tuf (umbrella), repository-service-tuf-api, repository-service-tuf-cli, repository-service-tuf-worker. They have multiple components and maybe in the future we will have more (analitics, webui, etc...). Instead of having it be under the ossf organization, they think it'd be a better structure to have it under another org also owned by OpenSSF. More detailed rationale:

• The development and contribution experience is not good having to search the repositories/components in a bigger repositories such as ossf
• The same for the user experience, to report a bug or something
• They use issues and milestones , per component/repositories. But the RSTUF roadmap is controlled by GitHub Projects. They also think it's very confused having the Projects on top of Organization with multiple parts.

Hopefully I've captured their concerns accurately (please let me know if I got something wrong!). The main thing I'm trying to do is highlight something unusual ahead of time, so that people can think it through.

[david-a-wheeler]

BTW: To get going, we can create this as a separate organization while the TAC decides if that's okay. If it's not okay, we can move things.

[jhutchings1]

You can put all of these together under a single GitHub Enterprise account if you want them grouped together for manageability, billing, etc. It doesn't particularly help with discoverability, however. https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-enterprise-accounts

[ljharb]

Discoverability is solved pretty easily with an org-level readme that points to all related orgs.

[kairoaraujo]

Discoverability is solved pretty easily with an org-level readme that points to all related orgs.

The idea is not to have multiple organizations for RSTUF, but one repository-service-tuf organization and all the repositories as part of this organization.

[ljharb]

@kairoaraujo sorry, to clarify, i meant that discovery of all OpenSSF-adjacent orgs is pretty easy with an OpenSSF org readme that points to all the sub-orgs, including repositry-service-tuf

[bobcallaway]

I don't have a problem with having separate GH orgs as long as we have clear docs pointing to the correct locations and affiliations appropriately noted.

[JLLeitschuh]

Would org-wide policies, for example, a SECURITY.md file be the same across all orgs, or be unique? If they are the same, then there may need to be some automation to automatically sync the .github repository between these different organizations.

[ljharb]

@JLLeitschuh i think potentially they could be different, but in the cases where they're desired to be the same, we'd indeed set up a github action on a cron in all the non-ossf orgs, to keep them in sync.

[dlorenc]

Sgtm on the separate org.

[inferno-chromium]

Seperate org sounds fine to me as well.

[hythloda]

This I think is done: https://github.com/repository-service-tuf
Soon when we have the Github Enterprise Account it will be tied with OpenSSF.

[SecurityCRob]

can this issue be closed now?

[kairoaraujo]

@SecurityCRob
Yes, RSTUF is already using the https://github.com/repository-service-tuf
Thank you!