New Technical Initiatives process realignment

[marcelamelara]

The labs process proposal and updates to the sandbox project entry requirements have raised several broader issues regarding TI gives and gets, Project sponsorships and repo creation. As authors of these two proposals, @justaugustus and I also had a private discussion on these topics.

This issue intends to record and summarize specific points/gaps raised in these two proposals that probably warrant a bit more discussion, rather than attempting to incorporate all of these points into these proposals.

From these discussions, we have identified the following needs that are not clearly covered or need revision in our current TI lifecycle docs:

1. A process for small single-maintainer/single-org projects to join OpenSSF at sandbox level -- proposed in Add the OpenSSF labs process #421, Relax Sandbox entry requirements and clarify WG sponsorship #599
2. A process for WGs and SIGs to create new GitHub repositories for new software/spec projects -- proposed in Add the OpenSSF labs process #421, possible alternative
3. Clarity on the definition of a Project -- Our current docs heavily focus on software, but specs are also very common. Both need GH repos that meet specific security practices.
4. Clarity on which entities / TIs can sponsor and oversee Projects -- Currently, the TAC may sponsor a Project directly (per Relax Sandbox entry requirements and clarify WG sponsorship #599, we want to move away from this), and process for hosting Projects under SIGs (increasingly common) is underspecified/unclear.
5. Clarity on Security Baseline for spec vs. software Projects -- When do spec repos need to start applying stricter security requirements?
6. Realignment on TI gives and gets will likely be needed based on these changes

[marcelamelara]

@justaugustus Please add anything I missed from our discussion today!

[justaugustus]

Thanks for capturing this, @marcelamelara!
This is an excellent description of where the gaps are and summarizes our previous convo nicely.

A few additions and thoughts from my side:

On items 1 and 4 (Sandbox entry + sponsorship): #599 is intended to address these directly. Based on review feedback from @gkunz, @marcelamelara, and @puerco, I'm updating #599 to shift from a time-gated maintainer growth requirement to an inactivity-based archival model — which better aligns with the spirit of lowering the Sandbox entry bar while still maintaining accountability.

On item 2 (WG/SIG repo creation): I think this is the most important gap to tackle next. Our current docs effectively conflate "repository" with "project," but these are distinct concepts:

• Repositories are resources. WGs, SIGs, or projects/technical initiatives may own them. A WG might have tooling, CI infrastructure, or exploratory code that may not need formal project lifecycle status.
• Projects/Technical Initiatives are the governed entity that moves through the Sandbox —> Incubating —> Graduated lifecycle. A project may span multiple repositories.
• Repo creation should be sponsored through a WG, even for repos owned by a SIG. This keeps the WG as the governance layer, consistent with the direction in Relax Sandbox entry requirements and clarify WG sponsorship #599.

Kubernetes has a useful model here: their repository guidelines separate repo creation (tiered: Associated, SIG, Core) from project lifecycle. SIG repos are created through a lightweight request process — SIG charter approval + issue against kubernetes/org — without requiring a full project proposal. If the effort matures into something that warrants formal lifecycle tracking, it enters the project process at that point.

The OpenSSF context is different in some important ways (LF IP transfer, OSPS Security Baseline requirements, smaller WG count), but the principle of separating "I need a repo for WG work" from "I'm proposing a new project" seems directly applicable. This also addresses @mlieberman85's observation on #599 that the current process doesn't support projects naturally spinning out of WG/SIG work.

On item 3 (definition of Project — software vs. specs): I think this needs both an OSPS Security Baseline adjustment and lifecycle milestone revision. What "Incubating" means for a spec is fundamentally different from what it means for software — adoption, maturity criteria, and security requirements all look different. Worth scoping out, but I'd suggest tackling this after items 1, 2, and 4 are resolved since those are more immediately blocking.

On item 5 (Security Baseline for specs): Related to item 3 — would defer to that discussion.

On item 6 (TI gives and gets): Agree this will likely need realignment once the other items settle. I'd suggest treating this as the capstone rather than trying to address it in parallel.

Suggested priority ordering (for discussion, not prescriptive):

1. Items 1 + 4 —> Relax Sandbox entry requirements and clarify WG sponsorship #599 (in progress, nearing consensus)
2. Item 2 —> Repo creation process (next priority — blocks practical WG work)
3. Items 3 + 5 —> Project definition + spec baselines (important but less immediately blocking)
4. Item 6 —> TI gives/gets realignment (capstone, depends on 1-3)

[lehors]

Clarity on which entities / TIs can sponsor and oversee Projects -- Currently, the TAC may sponsor a Project directly (per #599, we want to move away from this), and process for hosting Projects under SIGs (increasingly common) is underspecified/unclear.

Can someone please explain the motivation to no longer have projects report directly to the TAC? I believe this was always intended to be an exception rather the norm but I don't know why we should change what we have in this regard. And I don't know who "we" is in the above statement but it doesn't include me. :-)

Note that it's not that I'm against the proposed change per se, it's just that it seems to be a case of trying to fix what's not broken.

[steiza]

This is great!

I think I'm missing some context - it sounds like there was a potential sandbox project that we wanted to be part of the OpenSSF, but it didn't work for some reason? I'll have to get the details. Regardless:

Our current docs effectively conflate "repository" with "project,"

100%. About a third of https://github.com/ossf/tac#projects are a single repo in https://github.com/ossf/, the other two thirds have their own organization that's part of https://github.com/enterprises/openssf.

It's fine if a project wants to start out as a repo in https://github.com/ossf, but as it matures it's very likely to need multiple repositories.

A process for small single-maintainer/single-org projects to join OpenSSF at sandbox level

I'm less certain about this, but I guess it depends on how we view the sandbox level. There are certainly individuals who want to start projects in the OpenSSF who aren't ready for what the sandbox level is today. But also there's staff time and funding (up to $30k / year!) as outlined in https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md.

An alternative here would be clearer guidance as to what a pre-sandbox project gets, and how they should operate - sort of a pre-sandbox gives and gets. Maybe we could create a channel in the OpenSSF Slack, and suggest they create a free GitHub organization with a public repository (and then when they become sandbox that could either transfer into https://github.com/ossf or the org could become part of https://github.com/enterprises/openssf). On the other hand, maybe this is just re-inventing the labs process.

There are failure modes of a single maintainer that I want to avoid - a startup that pivots to another direction, or a company who is promoting what their product does as a LF / OpenSSF "industry standard" because they wrote a spec themselves and became a sandbox project.

Clarity on which entities / TIs can sponsor and oversee Projects

I'm on the fence here. On the one hand, it's easier for outside folks to understand if we say "you must report to a working group", on the other hand, we do have a project reporting to the TAC today (Sigstore), and we may want to have more in the future.

[lehors]

I think I'm missing some context - it sounds like there was a potential sandbox project that we wanted to be part of the OpenSSF, but it didn't work for some reason?

That's correct. I think we've had a few cases like this over time and the last one was recently brought up by @puerco in the SLSA group. He has a tool he'd like to contribute but for which he is the sole maintainer.

[marcelamelara]

Can someone please explain the motivation to no longer have projects report directly to the TAC? I believe this was always intended to be an exception rather the norm but I don't know why we should change what we have in this regard. And I don't know who "we" is in the above statement but it doesn't include me. :-)

Maybe this was me reading more into the discussion on #599 than I needed to! You're right that this is technically not broken, but I don't thinks it's entirely currently clear from the lifecycle docs that Projects reporting to the TAC is intended to be the exception, not the norm. So I'm coming from a place of wanting to disambiguate.