-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add clarity wrt SIGs that need to be projects #348
Conversation
When SIGs produce code or specification, they need to be projects, but this was not fully clear before. Aiming to clarify this. Signed-off-by: Mihai Maruseac <[email protected]>
@mihaimaruseac Thanks for your PR. While I agree that clarifications in the process are needed, the distinction between SIG and Project isn't strictly about code vs. no code. It's about scope, rather. SIGs are meant to be more independently managed within the hosting TI, considerably narrower in scope, and have a shorter lifetime. But this doesn't preclude the SIG from producing code that is experimental or a PoC for a spec. On the other hand, if the SIG eventually intends to create production-quality software beyond PoC, that's when I think it makes sense to migrate to a Project designation a Project designation since the Project lifecycle includes more software-related requirements. Again, I think our process docs would benefit from clarity around these details, but I don't think we should discourage SIGs from producing any code at all. These are my thoughts at least, others on the TAC may have a different view. |
I agree with @marcelamelara. I think the proposed wording is a bit too strong. Our [governance structure]9https://github.com/ossf/tac/blob/main/organizational-structure-overview.md) states that the "primary output" of a SIG is "not software". This implies that it could be a secondary output and clearly does not prohibit any software development. |
Signed-off-by: Mihai Maruseac <[email protected]>
Thank you for reviewing. I've made some amendments to the wording to include the feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on revised changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the revisions @mihaimaruseac ! LGTM.
I also think we need a changelog entry for this one? Or should we consider this an editorial change? |
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Mihai Maruseac <[email protected]>
I can add one if needed. |
Signed-off-by: Mihai Maruseac <[email protected]>
b9d5446
to
8220606
Compare
Thanks so much @mihaimaruseac ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
When SIGs produce code or specification, they need to be projects, but this was not fully clear before. Aiming to clarify this.