TAC sponsor should be sandbox stage requirement for WGs #262
Conversation
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
|
I'm not necessarily against this but what is the basis for your claim that "the intent is for WGs to have TAC sponsor before applying for sandbox status"? |
|
I should have clarified this in the PR description. I posed an initial question about why the TAC sponsor (as currently documented) doesn't seem to be required for WGs before the incubating stage, even though I was under the impression that TAC sponsors were required sooner. A couple of folks replied that the intent apparently was to have a TAC sponsor be a requirement from the start, although the docs don't currently reflect this. If this is open for debate, we can close this PR and open up an issue first. CC @SecurityCRob and @steiza who had chimed in on Slack as well. |
|
Talking to some project leads, it looks like a TAC sponsor was also needed to accept recent projects like protobom and SBOMit as a sandbox project (within the Security Tooling WG) though the project lifecycle docs don't reflect this. So I'll be pushing some updates to align with our current process. EDIT: It looks like the ambiguity largely stems from what's documented in the TI Gives and Gets vs the actual lifecycle docs. We may at some point want to refactor these documents to reduce redundancies and/or resolve discrepancies. |
…ement Signed-off-by: Marcela Melara <marcela.melara@intel.com>
| @@ -44,7 +44,7 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa | |||
| * Provides project updates to OpenSSF Marketing Committee as requested. | |||
|
|
|||
| #### Project Support | |||
| * Receives guidance on technical direction from TAC. | |||
| * Receives a TAC and WG sponsor for guidance on technical direction. | |||
There was a problem hiding this comment.
This is a bit different than what we defined for SIGs, which are similar to Projects in that they can report directly to the TAC or to a WG.
You can see the details of that discussion on #182, but where we landed was to define near the top of https://github.com/ossf/tac/blob/main/process/sig-lifecycle.md:
SIGs may report to a WG or directly to the TAC as their governing body.
... and then after that refer to their governing body instead of WG or TAC.
There's definitely a balance here. On one hand, we don't want a TAC vote for everything or we risk the TAC being a bottleneck for the organization to get anything done. On the other hand, the way the process is currently set up, any change in lifecycle involves a pull request in the TAC repo, and it is nice to be at least informed of changes taking place across the org.
I would be in favor of WGs adopting Projects at the Sandbox stage without requiring TAC approval, but I'm open to further discussion!
There was a problem hiding this comment.
Ah yes! You found this discrepancy yourself - see also the discussion on #263 (comment)
There was a problem hiding this comment.
My initial reason for spelling it out like this is that several recent projects like SBOMit and protobom have sought out a TAC sponsor to become sandbox. I totally agree that we shouldn't necessarily require TAC approval for every single TI either, so as you say, there's a balance to be struck. But the current TI Gives and Gets seems to make this a requirement for all TIs. So, some docs need to be adjusted, I'm just not sure where we want to draw the line.
There was a problem hiding this comment.
I think the TI Gives + Gets is the odd one out here, so how about we do something like:
Change https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md?plain=1#L17:
* TI must find an aligned WG to host the TI or must have a TAC sponsor that can help guide the TI through processes.
Could also consider and/or.
We could also consider changing https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md?plain=1#L27C2-L27C64:
* TI receives guidance on technical direction if they have a TAC sponsor
I did a quick look at https://github.com/ossf/tac/tree/main/process/templates to ensure the Project and SIG templates don't explicitly require a TAC sponsor, so I think we're good there.
There was a problem hiding this comment.
Thanks for these suggestions! What I like is that these will actually lower the barrier to entry for sandbox Projects and SIGs a little bit, so I'm definitely happy to adjust the TI Gives + Gets.
There was a problem hiding this comment.
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? This is something we ought to clarify in the docs.
There was a problem hiding this comment.
Moving this discussion over to #268 .
Signed-off-by: Marcela Melara <marcela.melara@intel.com>
The current WG lifecycle process docs don't currently require a TAC sponsor until after the sandbox stage has been reached, even though the intent is for WGs the have TAC sponsor before applying for sandbox status. This PR adjusts the WG lifecycle process to reflect that having a TAC sponsor should be a requirement for WGs when applying for the sandbox stage.