Ensure consistent requirements between TI lifecycle docs

[marcelamelara]

The TI Gives + Gets currently diverge from the requirements for TI lifecycle stages (WG, Project and SIG).

There are two areas where we need to evaluate the docs for consistency and completeness:

• Role of the TAC sponsor (Clarify role and expectations for TAC sponsors of TIs #263)
• Requirements for each type of TI at each stage

This issue is meant to track the tasks needed to resolve any remaining inconsistencies and missing requirements:

• Role of TAC sponsor (TAC sponsor should be sandbox stage requirement for WGs #262)
• Requirements for WGs
• Requirements for SIFs
• Requirements for Projects
• Requirements for SIGs
• Ensure alignment between TI Gives+Gets, lifecycle docs, templates (Update incubating TI Gives+Gets to match lifecycle/templates #295, Update graduated TI Gives+Gets to match lifecycle/templates #296, Update sandbox stage TI Gives+Gets to match lifecycle/templates #297)

Per the 2/20/2024 TAC meeting discussion, there's a need to revisit and document specific repo-structure requirements for TIs (e.g., charter updates, other .md files, etc).

There's also a desire to lower the barrier to entry for non-WG sandbox stage TIs and make TAC approval optional.
For instance, the TI G+Gs currently require sandbox TIs to adhere to the SSDGP and the Open Source Consumption Manifesto. These requirements only make sense for project TIs, and it's not clear if these are too steep a requirement for sandbox-level projects.

[lehors]

I think it's a healthy thing to do to review what we have and make sure the differences we have are intentional and not just merely accidental. However, we shouldn't assume that we ought to have alignment across all TIs. Some differences are intentional and ought to be kept. We do not want the TAC to be the sole point of control. Delegation of that control is key to scalability.

[marcelamelara]

Totally agree. I think part of the current issue is that the TI G+Gs don't always make the distinction between different types of TIs and their specific requirements. So we have this muddled set of requirements at the moment (in that doc). My ideal outcome for this issue would be to have the lifecycle docs be the clear authoritative source for requirements, and deduplicate this information from the Gives + Gets to avoid confusion :)

[marcelamelara]

Moving this discussion from https://github.com/ossf/tac/pull/262/files#r1491166612 here.

My summary:

• Should Projects require TAC approval for lifecycle transitions? (SIGs currently do not)
• How do we reconcile the need for opening a PR in this repo to submit a project's or SIG's sandbox application (which effectively amounts to needing some form of TAC approval) with the desire to make the TAC approval optional for projects and SIGs? Is this really about online vs offline TAC votes?

@steiza please let me know if I missed anything!

[lehors]

My summary:

* Should SIGs and Projects _require_ TAC approval for lifecycle transitions?

SIGs should not for sure.

* How do we reconcile the need for opening a PR in this repo to submit a project's or SIG's sandbox application (which effectively amounts to a TAC approval) with the desire to make the TAC approval optional for projects and SIGs? Is this really about online vs offline TAC votes?

For SIGs we clearly state that:

SIGs can be created and managed without formal approval from the TAC.
[...]
Because no formal approval by the TAC is required the PR can be merged by any TAC or staff member.

https://github.com/ossf/tac/blob/main/process/sig-lifecycle.md#sig-creation-or-change-of-lifecycle-stage

[marcelamelara]

Yes! I went back and edited my questions afterwards to adjust for the fact that this is already clearly laid out for SIGs.

[lehors]

Something could probably be done to make that kind of information easier to find but this might take some skilled person.

[SecurityCRob]

My summary:

* Should SIGs and Projects _require_ TAC approval for lifecycle transitions?

SIGs should not for sure.

* How do we reconcile the need for opening a PR in this repo to submit a project's or SIG's sandbox application (which effectively amounts to a TAC approval) with the desire to make the TAC approval optional for projects and SIGs? Is this really about online vs offline TAC votes?

For SIGs we clearly state that:

SIGs can be created and managed without formal approval from the TAC.
[...]
Because no formal approval by the TAC is required the PR can be merged by any TAC or staff member.

https://github.com/ossf/tac/blob/main/process/sig-lifecycle.md#sig-creation-or-change-of-lifecycle-stage

Agreed

[SecurityCRob]

Something could probably be done to make that kind of information easier to find but this might take some skilled person.

Also agreed. We need to make this stuff better accessible. updating the landing page will help, but more ideas and suggestions are welcome.

[SecurityCRob]

SANDBOX
#274
#282
#275
INCUBATING
#276
#277
#278
GRADUATED
#279
#280
#281

[marcelamelara]

With the updated templates, we'll want to get the TI_lifecycle.md docs in sync next as well.

[SecurityCRob]

Do we think that the requirements are now aligned between the project, WG, ans SIG documents? What needs adjusted for the Gives and Gets and who is interested in fleshing out "SIF" (if we still desire to have that category?)?

[marcelamelara]

Thanks for ping on this. I think once #295, #296 and #297 are merged, we'll be there.

[marcelamelara]

I think we can close this now. One piece we have left to resolve is the discussion from #85, we can focus the conversation in that issue.