Update SIG processes and ensure consistency & alignment with WG & project processes

[SecurityCRob]

TAC has good documentation around new project creation & lifecycle & working group lifecycle- https://github.com/ossf/tac/blob/main/process/project-lifecycle.md , https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md

Comparability, SIG documentation is lacking - https://github.com/ossf/tac/blob/main/process/sig-lifecycle.md

No documentation exists today for Special Interest Funds (SIFs) or Affiliated Projects (APs)

The TAC should ensure clearly documented processes exist that describe:

• Special interest Groups(SIG) have an adoption and lifecycle process that describes stages from beginning to possible eventual retirement of these groups
• gives/gets for each level of the SIG lifecycle should be
• Document who evaluates and votes upon creation/retirement/modification of these groups - TAC, WG, other?
• SIFs and APs should be clearly documented for proposal, adoption, and lifecycle processes
• documentation/language updated in WG/SIG charters, readme's, & security.md's that accurately describes desired processes for membership criteria, membership ladders/rewarding contributions, documentation how group votes are conducted and eligibility requirements

[lehors]

I agree about the SIFs and APs (if that's even really how they are called, I've seen various instances of Affiliated vs Associated Projects for instance.)
Regarding SIGs, although what we have is indeed very minimal I must admit not to know what is actually lacking.

The reality is that the majority of the projects and WGs lifecycle isn't used so I'm hesitant to create more stuff that may not be used either. From that point of view, I think it's better to add stuff in response to actual needs. What are the needs that are not met today?

[SecurityCRob]

The guidance does not need to be heavy, but should inform folks any required steps or things to care about so they can run with it and go do great things.

[steiza]

We might need to update https://github.com/ossf/tac/blob/main/organizational-structure-overview.md as part of this work.

Currently that document describes SIGs as reporting to a WG, not the TAC (although even if we keep that structure, we can of course provide lightweight guidance on adoption criteria and lifecycle process).

[AevaOnline]

The existing documentation does not cover SIFs or APs, as my previous attempts to quantify those were post-hoc and encountered organizational challenges.

On the topic of WGs and SIGs, refining the process from last year, and normalizing it across WGs and SIGs, seems entirely appropriate to me. Are there specific areas of friction or fragmentation that folks would like to address?

[hythloda]

This was brought up in the TAC with @torgo @ware @bobcallaway @steiza @hythloda volunteering to help
Do want a zoom meeting to get this started? Or async?

[ware]

I'll defer to others. I can do either.

[lehors]

We might need to update https://github.com/ossf/tac/blob/main/organizational-structure-overview.md as part of this work.

Currently that document describes SIGs as reporting to a WG, not the TAC (although even if we keep that structure, we can of course provide lightweight guidance on adoption criteria and lifecycle process).

Are you saying we should allow SIGs to be reporting to the TAC or all SIGs should report to the TAC?
I think the former is fine. This would be consistent with allowing projects to report directly to the TAC. I don't think we want all SIGs to report to the TAC though. That'd be a major change from how things have been done and I'm not sure what the gain would be.
What I think we might want to do is define the process WGs need to follow to create SIGs so that it's done consistently throughout the org.

[steiza]

This will not be an easy issue to solve, but at the same time we have to start somewhere. To that end I have started OpenSSF Workstream Taxonomy (EDIT: updated link for wider access) to cover scope, questions, and exit criteria, as well as existing hierarchy and references. Let's start the process by asynchronously collaborating there, and then use that to determine next steps.

[hythloda]

This will not be an easy issue to solve, but at the same time we have to start somewhere. To that end I have started OpenSSF Workstream Taxonomy (EDIT: updated link for wider access) to cover scope, questions, and exit criteria, as well as existing hierarchy and references. Let's start the process by asynchronously collaborating there, and then use that to determine next steps.

This is a great start! @torgo @ware @bobcallaway did you get a chance to see it?

[hythloda]

This is something that really needs some thoughts/ideas/comments. Just today I noticed that we have Alpha-Omega defined twice in our Intro:

[SecurityCRob]

I agree, we should figure out what kind of thing it really is and manage it appropriately from there. I would suggest A-O be considered a “project” under the IDing Sec Threat WG, and it aligns and reports up through them, understanding that the project itself has a special funding/management structure (as a SIF/AP). This will help streamline and make our reporting and organization more consistent as opposed to spinning up additional work/streams aka “corner cases”, “special snowflakes”, et.al..

[steiza]

Today I learned about OpenSSF Associated Projects doc, which might be helpful after we complete the SIG part of this workstream.

[david-a-wheeler]

My understanding was that "project" was to be used for efforts that focused on code, while SIG was to be used for efforts that didn't focus on code. E.g., the MFA distribution effort would be considered a SIG. I don't think everything should have to report directly to the TAC; the TAC is busy enough & we don't want all things to bottleneck through a few overworked people. Most SIGs are part of WGs; we need to make sure the WGs are monitoring their SIGs, and then the TAC doesn't have to do everything.

If I'm mistaken, or a change in direction is desired, that's okay too, making it clear is the key.

[lehors]

Is anyone saying all SIGs should report to the TAC? I think we should make it possible to have SIGs under the TAC but I expect the majority to still report to a WG.

[SecurityCRob]

changes have been merged to align all TI-types with consistent stages: Sandbox, Incubation, Graduation, and Archive. "Gives and Gets" are being discussed as part of the Ops Model work, and will added into TI documentation once agreed upon.