Update branch based on discussions at 07-26-22 TAC meeting

Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com>

organizational-structure-overview.md

@@ -17,9 +17,9 @@ The OpenSSF is comprised of instances of the following categories of official gr
    - Technical Initiatives usually manage one or more GitHub repos of their own and may have separate meetings.
 - 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.).
 - A **Working Group** (WG) focuses on developing other types of deliverables than software such as guides, specifications, and educational material, or conducting initiatives such as an education outreach. While a WG does not produce open source software as a primary artifact it may launch Projects that do so. A WG may also launch Special Interest Groups (SIG) to perform specific tasks. WGs often include some open source code, or use licensed software, in fulfilment of their Charter.
-- **Special Interest Groups** (SIG) are under the direct governance of their reporting WGs and are bound to achieving a very specific goal. 
-- A **Technical Deliverable** can be an open source licensed software and its supporting artifacts, a specification, or a technical guide. This is a technical artifact produced by a Technical Initiative.
-- A **Service** is a Technical Initiative in which software is either built or acquired to support or automate OSSF transactions.
+- **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.
+- A **Technical Deliverable** can be an open source licensed software and its supporting artifacts, a specification, a technical guide, or a service. Produced by a Technical Initiative, Technical Deliverables are a technical artifact or an ongoing service offering in the public domain. Refer to **Service** for additional clarity service offerings.
+  - A **Service** is a Technical Deliverable in which software is either built or acquired to support or automate OSSF transactions.
 
 The following table describes the main types of groups and their characteristics.
 

process/project-lifecycle.md

@@ -51,7 +51,7 @@ The OpenSSF Sandbox is the entry point for early stage Projects and has four goa
 #### Sandbox Entry Requirements and Considerations
 
 * Projects must have a minimum of two maintainers with different organization affiliations.
-* Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project.
+* Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code needed for an OpenSSF WG to work be kept within their repository and will not function as a project in its own right. Should initial WG code grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project.
 * If contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF).
 
 See [Submission Process](#submission-process) below and [Sandbox application](templates/PROJECT_NAME_sandbox_stage.md).
@@ -84,8 +84,8 @@ Incubating projects represent maturing but not fully realized projects. Incubati
 #### Incubation Entry Requirements and Considerations
 
 * Projects must have a minimum of three maintainers with a minimum of two different organization affiliations.
-* Projects should be able to show adoption by multiple parties and adoption's value to the open source community and/or end users (may include adoption of beta/early versions).
-* Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project.
+* Projects should be able to show adoption by multiple parties and adoption's value to the open source community and/or end users (may include adoption of beta/early versions) with the intent to showcase wide adoption by the project's consumers.
+* Projects must be aligned with the OpenSSF mission _and_ either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code needed for an OpenSSF WG to work be kept within their repository and will not function as a project in its own right. Should initial WG code grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project.
 * Projects must have documented, initial project governance.
 
 #### Project Process: Sandbox to Incubation and direct entry to Incubation
@@ -123,7 +123,7 @@ Graduated projects signal the highest level of maturity for an OpenSSF project.
 
 * Projects must have maintainers with a minimum of three different organizational affiliations.
 * Projects must be aligned with the OpenSSF mission and be a novel approach for existing areas or address an unfulfilled need. Projects with duplicate, similar or competing fuctionality to an existing OpenSSF project may be denied Graduation status if the TAC does not see technical justification for overlapping projects.
-* Projects must be able to show adoption by multiple parties, which could be production deployments or substantial use by established open source communities, and demonstrate the value of that adoption to either the end users or the open source community.
+* Projects must be able to show adoption by multiple parties, which could be production deployments or substantial use by established open source communities, and demonstrate the value of that adoption to either the end users or the open source community —  effectively wide adoption by the project's consumers.
 * Projects must be able to show a consistent release cadence.
 * Projects must have documented project governance and be able to demonstrate that governance in action.
 * When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations.

process/sig-lifecycle.md

@@ -1,6 +1,6 @@
 # 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 goal and not necessarily live for a very long time.
+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.
 
 The lifecycle of SIGs is therefore minimal and as follows.
 
@@ -10,4 +10,4 @@ The lifecycle of SIGs is therefore minimal and as follows.
 
 ## Inactive
 
-* The SIG is no longer active, either it has completed its mission or the mission was abandoned.
+* 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.