Rename Working Group (WG) to SIG everywhere

governance-charter.md

@@ -61,7 +61,7 @@ Efforts and initiatives that are too large, detailed, or important to be
 resolved in an issue or pull request are referred to as *projects*. These
 larger efforts often require collaboration between subject matter experts,
 the Technical Committee, and OpenTelemetry community members, and involve
-the creation of either a SIG or a Working Group. The [project management](https://github.com/open-telemetry/community/blob/main/project-management.md)
+the creation of a SIG. The [project management](https://github.com/open-telemetry/community/blob/main/project-management.md)
 document describes the process for creating and executing projects of this size.
 
 The GC is responsible for reviewing project proposals, aligning their execution

guides/contributor/donations.md

@@ -35,7 +35,7 @@ Committees follow to handle a prospective donation.
    The GC is also responsible for driving awareness in the community about
    the contribution and making sure all interested parties have a chance to
    object and/or contribute. The GC should work with any appropriate Special Interest
-   Groups or Working Groups to evaluate the donation proposal, consider alternatives,
+   Groups to evaluate the donation proposal, consider alternatives,
    and ensure OpenTelemetry has the resources required to support the donation. When
    considering alternatives, the GC should consider at least the CNCF ecosystem,
    and may also consider other well-known open source projects or alternatives proposed

project-management.md

@@ -40,4 +40,4 @@ The project lifecycle is as follows:
 * For a project to be approved, its pull request must be approved by a majority of GC members. If a project is approved, and all merge requirements are met, the pull request is merged. The project is then transitioned to the list of **Potential Projects**. This list is roughly ordered based on priority.
 * Potential projects are moved to the list of **Scheduled Projects** once they have a planned start date. Having a planned start date lets potential contributors know when they need to make themselves available, and get prepared to begin their work. Subject matter experts and participants who plan to do a lot of work – such as building prototypes – benefit greatly from having a start date, as they can plan for their participation with their employers and coworkers.
 * Once a project is begun, it is moved to the list of **Current Projects**. Projects are only started when the necessary resources are available to move them quickly to completion. This means that the necessary subject matter experts have been identified, and at least two TC members are committed to review and guide the project through the specification process.
-* Once work is complete, and the working group is no longer meeting, the project document is moved to the [completed projects](projects/completed-projects/) folder.
+* Once work is complete, and the SIG is no longer meeting, the project document is moved to the [completed projects](projects/completed-projects/) folder.

projects/ci-cd.md

@@ -1,10 +1,10 @@
-# CI/CD Observability Semantic Conventions Working Group
+# CI/CD Observability Semantic Conventions SIG
 
 [**CI/CD Project Board**](https://github.com/orgs/open-telemetry/projects/79)
 
 ## Description
 
-The goal of this working group is define the semantic conventions for CI/CD Observability and outline 
+The goal of this SIG is define the semantic conventions for CI/CD Observability and outline 
 a path forward for the OpenTelemetry community. 
 
 ### Why
@@ -22,7 +22,7 @@ is heavily looking for solutions and watching the related OTEP with interest.
 
 ## Deliverables
 
-The CI/CD observability working group is planning to deliver the [CI/CD Observability OTEP](https://github.com/open-telemetry/oteps/pull/223/files) with prototypes in the following areas:
+The CI/CD observability SIG is planning to deliver the [CI/CD Observability OTEP](https://github.com/open-telemetry/oteps/pull/223/files) with prototypes in the following areas:
 
 Only a few technologies are named here, so this is not all encompassing. As we build out these conventions, specifications, and prototypes we'll want to ensure that Observability is done within:
 
@@ -44,7 +44,7 @@ Current, non-complete list of Deliverables:
 ### Related OTEP(s)
 
 A related OTEP that is of great interest to the CI/CD OTEP is that of [Environment Variables as Context Propagators](https://github.com/open-telemetry/opentelemetry-specification/issues/740).
-This OTEP might be driven through other working groups, and isn't the direct focus of this working group, but is has wide arching impacts to enabling distributed tracing in batch systems. 
+This OTEP might be driven through other SIGs, and isn't the direct focus of this SIG, but is has wide arching impacts to enabling distributed tracing in batch systems. 
 As we work to define semantic conventions for CI/CD observability, this OTEP will without a doubt come into play in some form and thus is being listed as related but not a direct deliverable.
 
 
@@ -154,7 +154,7 @@ Estimated time-frame: 6-12 Months
 
 - [ ] TBD
 
-> Note: The working groups intent is to be nimble and able to adjust quickly.
+> Note: The SIG's intent is to be nimble and able to adjust quickly.
 
 ## Labels
 

projects/config.md

@@ -33,7 +33,7 @@ Sponsoring TC members
 * @carlosalberto
 * @jack-berg
 
-Engineers contributing to the working group
+Engineers contributing to the SIG
 
 * @MrAlias
 * @jack-berg

projects/database-client-semconv.md

@@ -29,7 +29,7 @@ Get the database client semantic conventions to stability, and afterwards update
 
 ## Timeline
 
-Goal is to stabilize Database client semantic conventions 3 months after the working group kicks off.
+Goal is to stabilize Database client semantic conventions 3 months after the SIG kicks off.
 
 ## Project Board
 

projects/faas.md

@@ -15,7 +15,7 @@ We want to ensure:
 * Cold start data capture and submission
 * The new TelemetryAPI is properly integrated and utilized by OpenTelemetry
 
-**This SIG will also serve as a working group for all FAAS topics going forward.**
+**This SIG will also serve as a interest group for all FAAS topics going forward.**
 
 ## Deliverables
 
@@ -71,8 +71,8 @@ CET Option: Wednesday @ 7 am PST
 
 ## Timeline
 
-1. New working group will be kicked off in January
-2. The WG has 6 weeks to propose improvements to the specification and solutions - Beginning of March
+1. New SIG will be kicked off in January
+2. The SIG has 6 weeks to propose improvements to the specification and solutions - Beginning of March
 3. OTeps and the first implementation in JavaScript will be reviewed by the community - All of March
 4. Implementation - we want to start with JavaScript and Python as our first target implementation languages - Beginning of April
 

projects/http.md

@@ -15,7 +15,7 @@ https://github.com/orgs/open-telemetry/projects/41
 
 The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny).
 
-* __Stage 1__: Working Group Preparation
+* __Stage 1__: SIG Preparation
 * __Stage 2__: Specification
 * __Stage 3__: Implementation
 
@@ -40,7 +40,7 @@ The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://d
 
 ## Meeting Times
 
-Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
+Once a project is started, the SIG should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
 
 ## Timeline
 

projects/k8s-semconv.md

@@ -1,4 +1,4 @@
-# K8s Conventions Working Group
+# K8s Conventions up
 
 ## Background and description
 
@@ -42,14 +42,14 @@ We are seeking domain experts to work on the introduction and stability of the K
 
 The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny).
 
-- Stage 1: Working Group Preparation
+- Stage 1: SIG Preparation
 - Stage 2: Stabilizing the Specification
 - Stage 3: Implementation
 
 ## Timeline
 
 Timeline
-Stage 1 (Working Group Preparation) is happening now.
+Stage 1 (SIG Preparation) is happening now.
 
 Stage 2 (Stabilizing the Specification) will begin as soon as we have adequate
 staffing for this project, and we coordinate weekly
@@ -108,7 +108,7 @@ and it should be relatively short we only need to update conformance to the spec
 
 ## SIG Meetings and Other Info
 
-*meeting time*: biweekly on Wednesday 8:00am PDT (+1 week offset from the Prometheus WG)
+*meeting time*: biweekly on Wednesday 8:00am PDT (+1 week offset from the SIG Prometheus Interoperability)
 
 *meeting-notes*: [Agenda](https://docs.google.com/document/d/17DqFVlLvO43neXXTwlSd1zcKjSRA8P3d0Y444QNwUTQ)
 

projects/mainframe.md

@@ -2,7 +2,7 @@
 
 ## Description
 
-As we see a growing interest from customers to use OpenTelemetry on the mainframe, we'd like to propose a working group to define and stabilize semantic conventions supporting the observability of the mainframe and to introduce instrumentation for programming languages present on the mainframe.
+As we see a growing interest from customers to use OpenTelemetry on the mainframe, we'd like to propose a SIG to define and stabilize semantic conventions supporting the observability of the mainframe and to introduce instrumentation for programming languages present on the mainframe.
 
 This proposal has been created as result of a [series of meetings](https://docs.google.com/document/d/14p-bpofozTL4n3jy6HZH_TKjoOXvog18G1HBRqq6liE/edit?pli=1#heading=h.pss2tdsd549w) for the topic “OpenTelemetry on Mainframe” with contributions from participants of multiple vendors and is based on [this document](https://docs.google.com/document/d/1SM5BmM4st8n4giWuqe1shqN98d37VG9C_-di1hG6sbg/edit#heading=h.q3h9nwmyzjva).  
 
@@ -34,7 +34,7 @@ Based on previous participation in the meeting for preparing this proposal, we f
 -   We invite everybody to join who is passionate about the mainframe.
 -   Two project leads who are willing to drive the project and address any issues which are not handled by other project members.
 -   At least two sponsoring TC (Technical Committee) members. TC sponsors are dedicated to attending meetings, reviewing proposals, and in general being aware of the state of the project and its technical details. TC sponsors guide the project through the spec process, keep the tracking issue up to date, and help to ensure that relevant community members provide input at the appropriate times.
--   Contributors from Semantic Conventions WG: \<to be added\>
+-   Contributors from Semantic Conventions SIG: \<to be added\>
 -   Maintainers or approvers: \<to be added\>
 
 ### Project Leads

projects/resources-and-entities.md

@@ -99,7 +99,7 @@ Engineers willing to write prototypes and contribute:
 - Collector - Tigran Najaryan, Bogdan Drutu (maintainer), Dmitrii Anoshin (maintainer).
 
 ## Meeting Times
-Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
+Once a project is started, the SIG should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
 
 ## Timeline
 

social-media-guide.md

@@ -54,7 +54,7 @@ An example of content we should strive to regularly post:
 - New blog posts, videos, or other content from the project.
 - New major releases, especially if accompanied by a blog.
 - Ecosystem developments (new exporters, new instrumentation, new tools, etc.)
-- New SIGs, WGs, events, or other groups.
+- New SIGs, events, or other groups.
 - Surveys, polls, or other community engagement activities.
 
 ## Official Social Media Accounts