Merge pull request #348 from mihaimaruseac/update-documentation

Add clarity wrt SIGs that need to be projects

CHANGELOG.md

@@ -1,5 +1,6 @@
 # OpenSSF TAC Changelog
 
+* 2024-06-27: Add clarity regarding SIG and projects (PR [#348](https://github.com/ossf/tac/pull/348))
 * 2024-06-11: Update funding application to include specific TI, lifecycle, and amount (PR [#344](https://github.com/ossf/tac/pull/344))
 * 2024-05-24: Improve election process and timeline
 * 2024-05-22: Add TI funding request to TAC decision process doc (PR [#329](https://github.com/ossf/tac/pull/329))

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's primary purpose is not to produce code or specifications (it can produce them as secondary goals, or as experimental POCs).
 
 # II. Lifecycle
 

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 should consider becoming a [project](./project-lifecycle.md) instead, especially if this becomes the main scope of the SIG.
 
 ## To become `Incubating`: