Question on scope of SIGs listed in the TAC repository

[PrinceAsiedu]

While reviewing the repository, I observed that only a few SIGs are represented.

I wanted to ask whether this list is intended to represent all OpenSSF SIGs, or if it is a curated subset (e.g., aligned with TAC oversight or a specific focus area).

Any clarification on the scope and selection criteria would be appreciated.

[steiza]

Mostly the problem has been that there are a lot of SIGs and the list is changing all the time!

I don't think we have formal requirements for having a SIG listed on https://github.com/ossf/tac/blob/main/README.md, but maybe it would be nice for the SIG to have a defined lifecycle stage in https://github.com/ossf/tac/tree/main/process/sig-lifecycle-documents. I don't think we've been keeping up with SIG lifecycle stages, but maybe the opportunity to be listed on the TAC README would be an incentive!

[lehors]

Maybe I'm just lazy but I'd rather go the other way and forgo trying to keep track of the SIGs in our README. Just because it's nearly impossible to do it accurately so we end up with a partial list which is misleading.

[marcelamelara]

forgo trying to keep track of the SIGs in our README

I agree. We probably need to clarify in our lifecycle that SIGs are expected to be under the governance of WGs, so each WG should be tracking their own SIGs (See #600)

[david-a-wheeler]

@madalinnneag - I know you'd love to have a single page (like on the TAC) for all SIGs and projects of the OpenSSF. You might want to comment here...

[lehors]

@madalinnneag - I know you'd love to have a single page (like on the TAC) for all SIGs and projects of the OpenSSF. You might want to comment here...

Who wouldn't? But are you going to maintain it? :-)

[david-a-wheeler]

@madalinnneag - comments?

[madalinnneag]

Dear all,

I recently discussed this idea with colleagues, and David kindly added me to this conversation; thank you for that.

While reviewing our website, I noticed that we currently list the WGs, but not the SIGs that operate within them.
From a community and engagement perspective, this may unintentionally limit visibility into a significant portion of the work happening across OpenSSF.

Many contributors and potential participants are not necessarily interested in the full scope of a WG; instead, they are often drawn to specific technical topics or initiatives, which are typically organized at the SIG level.
When SIGs are not easily discoverable from our main website, it can make it harder for people (especially newcomers) to understand where they can contribute or how to get involved.

It is true that information about SIGs can be found within individual WG GitHub repositories.
However, assembling a complete picture of OpenSSF activities currently requires navigating across multiple repositories and pages. From a usability standpoint, this can represent a meaningful barrier, particularly for those who are just starting to explore our ecosystem.

For these reasons, I would like to suggest creating a dedicated section or list within the existing Working Groups page where we could publish the SIGs that exist across OpenSSF.
Even a partial list would be valuable; in my view, some visibility is clearly better than none, and the list could evolve over time.

Regarding maintenance, one practical approach could be to leverage the periodic reporting that WG chairs already provide to the TAC. If each WG includes the current status of its SIGs in those updates, the same information could be used to keep the public list accurate without introducing significant additional overhead.

From a broader perspective, not having a visible list of SIGs may represent a missed opportunity to highlight the depth of our work and to attract new contributors who are looking for specific areas where they can engage.
Improving this visibility could strengthen onboarding, collaboration, and overall community growth.

If maintaining such a list at the TAC level is also useful, that is, of course, for you to decide.
My main intention is simply to help make the work of our SIGs more visible, accessible, and easier to engage with.

Thank you very much for considering this suggestion.

[marcelamelara]

Not at all opposed to listing SIGs on the OpenSSF website. Pulling @GeauxJD into the discussion, since I think he was doing some website updates some time back.

[justaugustus]

@ossf/tac — I've mentioned on a few TAC calls in the past that it'd be great if we had a community repo, similar to the Kubernetes project: https://github.com/kubernetes/community

While it's generated and a little bit off from the ideal directory structure, here's an example of what that could look like: https://github.com/justaugustus/ossf-community

Take a look and let me know if this is a direction you'd like me to continue to explore.

[madalinnneag]

From my perspective, this looks great.
Thank you very much for putting this together.
I think that from this point onwards, it should be straightforward to publish them on our website as well.
Do you anticipate this being easy to maintain?

[justaugustus]

From my perspective, this looks great. Thank you very much for putting this together.

Happy to help, @madalinnneag!

I think that from this point onwards, it should be straightforward to publish them on our website as well.

I'd need to learn a bit about the website workflow, so for now I'll say... "it depends"!
It's likely that openssf.org is updated via some CMS? If that's the case, we'd need some export/upload functionality to bridge the gap.
(I'm not sure that non-OpenSSF staff contributors have visibility into this process today.)

Do you anticipate this being easy to maintain?

Speaking strictly from the Kubernetes perspective, the update process is roughly:

• contributor makes changes to a top-level yaml file that contains the metadata for all governance groups
• contributor runs a make command that runs a Golang-based file generator under the covers to update the repo's subdirectories
• each subdirectory contains an OWNERS file which controls who has merge access to the content (we'd use CODEOWNERS instead)
• CI checks validate the content structure
• changes are reviewed, approved, and merged by the respective team

The workflow is generally simple, but would be cumbersome/intractable for folks who do not have a development environment set up or prefer a UI-based workflow.

I'd expect this repo to be primarily maintained by WG/TI members, so this may not be an issue, but would love to hear thoughts.

[PrinceAsiedu]

Thank you all for your comments and guidance on this.
@madalinnneag @david-a-wheeler @justaugustus, I’d appreciate any direction on how I can contribute to this effort and help maintain the list going forward.