Update SIG lifecycle doc #182
Conversation
steiza
changed the title
There was a problem hiding this comment.
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
....
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>
steiza
force-pushed
the
update-sig-process
branch
from
9bc8aa8
to
72a5679
Compare
|
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>
There was a problem hiding this comment.
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?
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:
So my recommendation would be that we just update the TAC README to reflect this legacy decision. |
|
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? |
SecurityCRob
added
documentation
|
|
||
| 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). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Do we have a definition of membership outside of the TAC? This has come up as a point of contention before.
There was a problem hiding this comment.
No, but this is good follow-on work!
process/sig-lifecycle.md
Outdated
| ## 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 |
There was a problem hiding this comment.
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
force-pushed
the
update-sig-process
branch
from
c709a2c
to
fd92ff4
Compare
Based on feedback from #182 Signed-off-by: Zach Steindler <steiza@github.com>
Based on feedback from #182 Signed-off-by: Zach Steindler <steiza@github.com>
Based on feedback from #182 Signed-off-by: Zach Steindler <steiza@github.com>
* 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>
For #161
Based on questions raised and community discussion