Add clarity wrt SIGs that need to be projects

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 <mihaimaruseac@google.com>
ossf · Jun 20, 2024 · c5a4e4d · c5a4e4d
1 parent 629838b
commit c5a4e4d
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/process/Technical_Initiative_Lifecycle.md b/process/Technical_Initiative_Lifecycle.md
@@ -21,7 +21,7 @@ flowchart TD
 
 The process is designed to be flexible to enable a Project to move in and out of a Working Group as deemed appropriate by the TAC.
 
-A SIG can be developed within a WG or Project to address a specific need.
+A SIG can be developed within a WG or Project to address a specific need. Note that a SIG cannot produce code or specifications.
 
 # II. Lifecycle
 

diff --git a/process/sig-lifecycle.md b/process/sig-lifecycle.md
@@ -22,7 +22,7 @@ The SIG life cycle begins with interested contributors deciding to undertake thi
 * 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
-* If the SIG starts to produce code or specifications, they should consider becoming a [project](./project-lifecycle.md) instead
+* If the SIG starts to produce code or specifications, they must migrate to a [project](./project-lifecycle.md) instead
 
 ## To become `Incubating`: