Donate/bootstrap ossf/community repo

[justaugustus]

Inspired by #595 and previous conversations, I'd like to present https://github.com/justaugustus/ossf-community as a solution to allow for easier discovery and management of governance group information.

Initial feedback from TAC meetings and other conversations appeared to be positive, so I'm going to formalize this request.

[steiza]

I think this is a great idea - I want to better understand the implementation.

What is the source of truth for the list of TIs, their current status, and which WG they report to?

Today I think it's a mix of:

• https://github.com/ossf/tac/blob/main/README.md (with an incomplete list of SIGs)
• The *-documents folders in https://github.com/ossf/tac/tree/main/process (but not all TIs have an established lifecycle stage)
• Lists that folks (like staff?) manually keep up-to-date

I love the idea of a script to keep these places up to date, but ideally the script would live in the same place as the source of truth so we don't have an additional place to update (like https://github.com/justaugustus/ossf-community/blob/main/groups.yaml) when we adopt a new TI, or a TI changes lifecycle, or co-chairs, or ...

So maybe the answer is to have a groups.yaml file in the TAC repo, that we update as part of the TI lifecycle process, and then a script uses that to update the README in the TAC repo?

It's tempting to try to make the lifecycle documents the source of truth, but there are changes (like co-chairs) that we want to track without updating the lifecycle documentation.

Does that make sense? Or do we literally want a separate community repository?

[lehors]

I was assuming that this would become the source of truth and we'd retire all other lists (as much as possible). We definitely don't want to add another one, right?

[TracyRagan]

I'm supportive of centralizing these details - can we add artwork as well.