Skip to content
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

Update SIG lifecycle doc #182

Merged
merged 5 commits into from
Sep 8, 2023
Merged

Update SIG lifecycle doc #182

merged 5 commits into from
Sep 8, 2023

Conversation

steiza
Copy link
Member

@steiza steiza commented Jul 7, 2023

For #161

Based on questions raised and community discussion

@steiza steiza requested a review from a team July 7, 2023 17:39
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
@steiza steiza changed the title For https://github.com/ossf/tac/issues/161 Update SIG lifecycle doc Jul 7, 2023
Copy link
Contributor

@lehors lehors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must admit not to understand part of this PR. It enumerates how to transition to various states with defining them. I think we should have both, as in:

Tentative
....
To become Tentative
....
Active
....
To become Active
....
Inactive
....
To become Inactive
....

process/sig-lifecycle.md Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
process/sig-lifecycle.md Outdated Show resolved Hide resolved
steiza and others added 3 commits August 4, 2023 10:14
Update SIG lifecycle doc based on questions raised and commuinity
discussion

Signed-off-by: Zach Steindler <steiza@github.com>
Additional edits forthcoming!

Co-authored-by: Joshua Lock <jlock@vmware.com>
Co-authored-by: Dustin Ingram <di@users.noreply.github.com>
Signed-off-by: Zach Steindler <steiza@github.com>
Also includes edits from code review feedback

Signed-off-by: Zach Steindler <steiza@github.com>
@lehors
Copy link
Contributor

lehors commented Aug 7, 2023

Looks pretty good but my comment about needed to define the different states before explaining how to change state still stands.

Signed-off-by: Zach Steindler <steiza@github.com>
Copy link
Member

@di di left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, my only question is a meta-question about what we plan to do with existing SIGs that are not fully aligned with these requirements, i.e. haven't been explicitly agreed upon by a governing body. Do we grandfather them in, or should we hold votes to retroactively approve them?

@steiza
Copy link
Member Author

steiza commented Aug 8, 2023

what we plan to do with existing SIGs that are not fully aligned with these requirements, i.e. haven't been explicitly agreed upon by a governing body

Good question! I had to go back and review my notes on OpenSSF Workstream Taxonomy - Existing hierarchy.

I think all the SIGs already correspond to a WG, except for https://github.com/ossf/diagrammers-society/ which reports to the TAC (which we are updating the docs to allow).

The docs also says:

This workstream will not undo previously made decisions

So my recommendation would be that we just update the TAC README to reflect this legacy decision.

@di
Copy link
Member

di commented Aug 8, 2023

The example I was thinking of is the "Great Artifact Repository Audit" effort which is not listed in your taxonomy doc. Specifically, the Securing Software Repos WG hasn't voted to create the SIG (in fact the issue about it is still open: ossf/wg-securing-software-repos#14), but AFAICT that work is a) ongoing regardless b) embodies a "SIG", at least in my opinion, and c) exists or should exist under that WG.

Copy link
Contributor

@lehors lehors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. The additional paragraph fulfills my request!

@steiza
Copy link
Member Author

steiza commented Aug 11, 2023

The example I was thinking of is the "Great Artifact Repository Audit" effort which is not listed in your taxonomy doc. Specifically, the Securing Software Repos WG hasn't voted to create the SIG (in fact the issue about it is still open: ossf/wg-securing-software-repos#14), but AFAICT that work is a) ongoing regardless b) embodies a "SIG", at least in my opinion, and c) exists or should exist under that WG.

This is a good call-out! It's not clear to me if the Great Artifact Repository Audit is legacy or not, as that work started in parallel with this effort to update the SIG lifecycle doc.

Can the Security Software Repos WG decide if they're officially adopting the Great Artifact Repository Audit, or if not, notify them so they can seek another WG (or the TAC) as their governing body?

Copy link
Contributor

@SecurityCRob SecurityCRob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with these updates clarifying SIGs.

@SecurityCRob SecurityCRob added documentation Improvements or additions to documentation administration For Review labels Aug 24, 2023

The lifecycle of SIGs is therefore minimal and as follows.
It is expected that the primary output of a SIG is not software. If the primary output is software, the work should be organized as a [project](./project-lifecycle.md).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any mechanisms for a SIG turning into a project? I have seen discussion in some of the groups that a body of work starts off mostly with a white paper or similar deliverable but over time there's interest in potentially extending it into code?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but this is good follow-on work!


## Active
SIG process should be minimal, however we do need some process to at least ensure we have an accurate list of all the active SIGs in the OpenSSF. This document uses "must" to describe what items are required, "should" to suggest items that should be strongly considered (but not required), and "may" for suggested guidance.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SIG process should be minimal, however we do need some process to at least ensure we have an accurate list of all the active SIGs in the OpenSSF.

Why?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure which part the "why" is directed at.

If it's the first part (the SIG process should be minimal) that's so there's less process friction and contributors can focus on their work and not navigating undue process.

In case the "why" is directed at the second part, we need a list of active SIGs to understand the activities of OpenSSF contributors for reporting on progress, ensuring the work is compatible with the OpenSSF's mission, etc.

## To become `Active`:

* A governing body must agree to govern the SIG
* The governing body may have its membership vote, with notice given at the meeting prior to the vote
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a definition of membership outside of the TAC? This has come up as a point of contention before.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but this is good follow-on work!

## Once `Active`:

* The governing body must list information about the SIG on its README, including current state, chairs, and a statement of focus, intent, goals, and/or deliverables
* SIGs may have a repository (prefixed with `sig-`) that include the information listed above
Copy link
Contributor

@lehors lehors Sep 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually don't think the sig- prefix is a good idea. I think we're better off not encoding in the repo name this kind of information that we might want to change in the future. For instance, if we hadn't had some repos with -wg in it we could have changed them to SIGs to be more aligned with other LF orgs. @mlieberman85 pointed out that a SIG might want to morph into a Project at some point. If we don't have sig- in the repo name this is just a matter of updating the README. If we have sig- in it it's more difficult to change.

Signed-off-by: Zach Steindler <steiza@github.com>
@steiza steiza merged commit 15a1ece into main Sep 8, 2023
3 checks passed
@steiza steiza deleted the update-sig-process branch September 8, 2023 17:43
steiza added a commit that referenced this pull request Sep 20, 2023
Based on feedback from #182

Signed-off-by: Zach Steindler <steiza@github.com>
lehors pushed a commit that referenced this pull request Sep 28, 2023
Based on feedback from #182

Signed-off-by: Zach Steindler <steiza@github.com>
lehors pushed a commit that referenced this pull request Oct 14, 2023
Based on feedback from #182

Signed-off-by: Zach Steindler <steiza@github.com>
steiza added a commit that referenced this pull request Oct 16, 2023
* Follow-on update to SIG process based on feedback from #182
* Standardize SIG stages to other Technical Initiatives: Sandbox, Incubating, Graduated, and Archived

---------

Signed-off-by: Zach Steindler <steiza@github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
administration documentation Improvements or additions to documentation For Review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants