Add the OpenSSF labs process

[marcelamelara]

This PR introduces the process for creating and managing pre-sandbox projects under a future OpenSSF-managed GitHub organization (name TBD). Ideally, all docs and templates related to this process would eventually be moved to a dedicated repo in that same GH org to separate it from the main TAC repo.

Resolves #264 .

[lehors]

LGTM but I recommend not mixing the terms project and lab as much as possible. In practice this is often difficult but at least in our documentation we should try to keep the two concepts distinct.

[camaleon2016]

I like this, and I agree with Arnaud on the changes. My only worry is the debt in created and then archived or abandoned labs. We may consider a policy or procedure for how long we maintain an archived lab before it's deleted.

[steiza]

A few minor questions and I think we need to decide what repo the labs proposals will live in - otherwise LGTM!

[steiza]

This is exactly the question - where should this content live? Since the TAC is the one reviewing the requests, maybe it makes sense to have this content in the TAC repo? And then the labs themselves will be part of an ossf-labs GitHub organization? Or will they be in the same ossf GitHub organization with something in their README that says they are a lab (e.g. pre-sandbox)?

[marcelamelara]

I'm a bit torn between this content living in the TAC repo and in a dedicated ossf-labs/onboarding repo, which the TAC would have access to. I see a few tradeoffs.

The biggest advantage of keeping this content in the TAC repo, I think, is that the overhead in getting this set up would be quite low, we already have a process for managing new incoming PRs, everyone has the necessary permissions etc.

The advantage of having this content live in the dedicated ossf-labs repo is that it would be more clearly associated with the labs, we could set the content up as a website, and if the need for a separate labs review committee ever arose, we wouldn't have to worry about separation of duties since it would become a matter of updating the repo maintainers. But it does (currently) increase the burden on the TAC and staff to maintain another repo.

FWIW, Hyperledger Labs, for example, does use a separate repo for labs onboarding.

@lehors what are your thoughts on this, since you have more experience with creating a lab space?

[gkunz]

Would transferring existing repositories over to the labs org require a full license and IP review as for "full" projects coming into the OpenSSF? That could create a significant overhead and we may want to trade-off the intention of making labs a very accessible path into the OpenSSF space and putting the necessary guardrails in place.

[marcelamelara]

I don't think transferring an existing repo to the labs org should require a full license and IP review, as long as they have one of the expected licenses and DCO. The full license and IP review becomes part of the transition requirement to sandbox stage. I can clarify this in the text.

CC'ing @Naomi-Wash @riaankleinhans to confirm this.

[marcelamelara]

I've updated the text with a note about this, please let me know what you think.

[marcelamelara]

My only worry is the debt in created and then archived or abandoned labs. We may consider a policy or procedure for how long we maintain an archived lab before it's deleted.

@camaleon2016 Is your concern more about whether we'll run out of space for new labs, or more about the optics of having a lot of archived labs?

[camaleon2016]

I think more about optics and who will bear the responsibility of maintaining account and record of issued labs and their disposition. Jay White (He/Him) Security Principal Program Manager Azure Office of the CTO OSS Ecosystem [Graphical user interface Description automatically generated] [cid:2fb3a606-0348-4159-8454-0d6fe57708cc]

…

________________________________ From: Marcela Melara ***@***.***> Sent: Thursday, January 9, 2025 11:59 AM To: ossf/tac ***@***.***> Cc: Jay White ***@***.***>; Mention ***@***.***> Subject: Re: [ossf/tac] Add the OpenSSF labs process (PR #421) My only worry is the debt in created and then archived or abandoned labs. We may consider a policy or procedure for how long we maintain an archived lab before it's deleted. @camaleon2016<https://github.com/camaleon2016> Is your concern more about whether we'll run out of space for new labs, or more about the optics of having a lot of archived labs? — Reply to this email directly, view it on GitHub<#421 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYSMSZVIV5W7O36I3D7UAO32J3IK5AVCNFSM6AAAAABTMMAIU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBRGE2DGNRYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[marcelamelara]

I think more about optics and who will bear the responsibility of maintaining account and record of issued labs and their disposition.

@camaleon2016 Gotcha. The current proposal has the TAC as the body responsible for reviewing new lab applications (much like we do with other TI lifecycle applications). Ideally, labs maintainers will either apply for sandbox status when they're ready, or submit an archival request to the TAC when deemed necessary. But the proposed process won't let labs go inactive for longer than 6 months, so the TAC would archive any repo that's been abandoned longer than that timeframe. Either way, the TAC would have the documentation for the approved and archived labs. Does this address your concerns?