Update SIG lifecycle doc (ossf#182)

For ossf#161

Update SIG lifecycle doc based on questions raised and community discussion

Signed-off-by: Zach Steindler <[email protected]>
Co-authored-by: Joshua Lock <[email protected]>
Co-authored-by: Dustin Ingram <[email protected]>

Author: 3 people

organizational-structure-overview.md

@@ -20,7 +20,7 @@ The OpenSSF is comprised of instances of the following categories of official gr
    - A WG may also launch Special Interest Groups (SIG) to perform specific tasks other than creating software.
    - WGs often include some open source code, or use licensed software, in fulfilment of their Charter.
 - A **Project** is a Technical Initiative focused on the development and ongoing support of open source licensed software (source code) and its supporting artifacts (technical documentation, etc.).
-- **Special Interest Groups** (SIG) are under the direct governance of their reporting WGs and are bound to achieving a very specific goal. These groups may be terminated upon completion of their designating tasking, continued for larger and ongoing efforts, or otherwise subject to the governance, structure, and termination policies of the WG they are under. The creation of a SIG must dictate the focus, intent, goals, and deliverable(s) as appropriate.
+- **Special Interest Groups** (SIG) are bound to achieving a very specific goal. These groups may be terminated upon completion of their designating tasking or continued for larger and ongoing efforts. The creation of a SIG must dictate the focus, intent, goals, and deliverable(s) as appropriate. SIGs may report to a WG or directly to the TAC.
 - A **Technical Deliverable** is any technical content produced by a Technical Initiative, such as open source licensed software, a specification, or a technical guide.
    - Each **Project** shall have at least one Technical Deliverable including open source licensed software; this is what defines a Project as distinct from other Technical Initiatives such as SIGs.
    - A **Service** is a publicly-run instance of software as a service, and is another form of Technical Deliverable distinct from the release of open source licensed software. This may be an operational output of a Technical Initiative in which software is either built or acquired to support or automate OSSF transactions.
@@ -31,7 +31,7 @@ The following table describes the main types of groups and their characteristics
 |------------|-------------------|---------------|------------------------|---------------
 | Working Group (WG) | unbounded | not software | to the TAC | normative
 | Project |	unbounded | software | either TAC or WG | normative
-| Special Interest Group (WG) | bounded | not software | to a WG | normative
+| Special Interest Group (WG) | bounded | not software | either TAC or WG | normative
 
 
 ### TODO

process/sig-lifecycle.md

@@ -1,13 +1,40 @@
 # Special Interest Group (SIG) Life Cycle
 
-Special Interest Groups are under the direct governance of a Working Group (WG) which can create and close them as necessary and appropriate. SIGs are expected to have a very specific goals and objectives at the time of their creation which may or may not define if they are terminable and is entirely dependent on the nature of the SIG.
+Special Interest Groups are bound to achieving a very specific goal. These groups may be terminated upon completion of their designating tasking or continued for larger and ongoing efforts. The creation of a SIG must dictate the focus, intent, goals, and deliverable(s) as appropriate. SIGs may report to a WG or directly to the TAC as their governing body.
 
-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).
 
-## 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.
 
-* The SIG is actively pursuing its goal.
+The SIG life cycle begins with interested contributors deciding to undertake this process, at which time the SIG is `Tentative`. A SIG becomes `Active` when a governing body agrees to take it on, at which point the SIG goes about achieving its goals and deliverables. Once that work is completed, or if the effort stalls out, the SIG becomes `End-of-Life` and some administrative cleanup will be done. The details for each phase follow.
 
-## Inactive
+## To become `Tentative`:
 
-* The SIG is no longer active, either it has completed its mission or the mission was abandoned. At which state, the WG the SIG is under will determine a termination status and record it within the corresponding repository.
+* This is the default state of a new SIG that is not yet active
+
+## 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
+
+## 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 regular meetings separate from their governing body, if so:
+  * They should appear on the OpenSSF calendar
+  * They should have a document with upcoming agendas and notes from past meetings
+
+## To become `End-of-Life`:
+
+* The chairs of a SIG can decide to conclude their work, in which case they must notify their governing body
+* The chairs of the governing body must periodically review their active SIGs and determine if any should end
+  * This review should happen at least annually
+  * The chairs of the governing body may have its membership vote, with notice given at the meeting prior to the vote
+
+## Once `End-of-Life`
+
+* The governing body must update their README to reflect that the SIG has ended
+  * They should list the SIG as end-of-life instead of removing it completely
+* If a repository exists, it should be marked read-only
+* If meetings are on the OpenSSF calendar, they should be removed
+* Any other administrative items (mailing lists, docs) should similarly be put to closure as needed