Merge branch 'main' into feature/tigran/entities

.cspell.yaml

@@ -15,6 +15,7 @@ words:
     - emea
     - faas
     - gitter
+    - gyliu513
     - Hostmetrics
     - jemmic
     - keptn

.github/workflows/reusable-markdown-link-check.yml

@@ -10,7 +10,7 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: Install markdown-link-check
-        run: npm install -g markdown-link-check@3
+        run: npm install -g markdown-link-check@3.11.2
 
       - name: Run markdown-link-check
         run: |

.github/workflows/spell-check.yml

@@ -8,6 +8,6 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: streetsidesoftware/cspell-action@v5
+      - uses: streetsidesoftware/cspell-action@v6
         with:
           config: .cspell.yaml

README.md

@@ -68,7 +68,7 @@ can access it via:
 
 * [Web](https://calendar.google.com/calendar/embed?src=c_2bf73e3b6b530da4babd444e72b76a6ad893a5c3f43cf40467abc7a9a897f977%40group.calendar.google.com)
 * [Google
-Calendar](https://calendar.google.com/calendar?cid=Y18yYmY3M2UzYjZiNTMwZGE0YmFiZDQ0NGU3MmI3NmE2YWQ4OTNhNWMzZjQzY2Y0MDQ2N2FiYzdhOWE4OTdmOTc3QGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20)
+Calendar](https://calendar.google.com/calendar?cid=c_2bf73e3b6b530da4babd444e72b76a6ad893a5c3f43cf40467abc7a9a897f977@group.calendar.google.com)
 * [iCalendar](https://calendar.google.com/calendar/ical/c_2bf73e3b6b530da4babd444e72b76a6ad893a5c3f43cf40467abc7a9a897f977%40group.calendar.google.com/public/basic.ics)
 
 The best way to subscribe to specific OpenTelemetry meeting series is to join the associated

gc-check-ins.md

@@ -0,0 +1,21 @@
+# Regular check-ins with SIG leads
+
+As defined in the [charter of the GC](./governance-charter.md#regular-check-ins-with-sig-leads) the GC will check in with maintainers of all long-term and short-term SIGs on a regular basis. During this check in,
+
+* any project files or roadmap entries should be reviewed to verify that they are still accurate.
+* if a SIG lead has any private concerns they wish to raise with the Governance Committee, this is an opportunity to do so.
+* the health of the SIG will be reviewed, and what measures can be applied to help the SIG.
+
+The check in process is as follows:
+
+* For each SIG a GC member is appointed as a GC liaison. The name of that person will be listed publicly.
+* If a GC member was the sponsor for [the formation of the SIG](https://github.com/open-telemetry/community/blob/main/project-management.md), they are by the GC liaison for this SIG.
+* If a GC member is the maintainer themselves, they are by default the GC liaison for this SIG.
+* The GC liaison is appointed for the duration of the project lifecycle, or until they do not get reelected into the GC. Outside of that regular duration, a GC liaison can resign by providing a named successor.
+* The GC liaison is responsible to check in with the maintainers at least once per month. This can either happen via a (private, non recorded) meeting or through a text-based conversation initiated by the GC liaison.
+* The GC liaison is responsible to bring the concerns of the SIG leads forward to the GC, and they are responsible for ensuring that all action items agreed upon during that check in are logged as issues on the project repository or community repository.
+* The GC liaison will attend the regular project meetings at least once per quarter. If this is difficult to accomplish due to timezone constraints, the GC liaison can be freed from this obligation by the GC. This exception should only rarely be approved.
+* The GC liaison and the maintainers are responsible to provide a quarterly health update, where they assess project health along three dimensions:
+  * Whether the SIG is making reasonable progress, and if published "On Schedule" relative to its own roadmap
+  * The "contributor experience": # of new contributors/triagers/maintainers, PR turnaround time, newbie-friendly issues, advancement opportunities, automation, etc
+  * The "maintainer experience": workload, burnout, collaboration, etc.

project-management.md

@@ -1,7 +1,12 @@
 # Project Management
 
-The OpenTelemetry community has limited bandwidth for managing changes which expand the scope of OpenTelemetry, or impact many SIGs within OpenTelemetry. There are three common scenarios which have this kind of impact.
-* Non-trivial changes to the OpenTelemetry specification.
+The OpenTelemetry community has limited bandwidth for managing changes which expand the scope of OpenTelemetry, or impact many SIGs within OpenTelemetry.
+
+These are common scenarios which have this kind of impact:
+
+* Non-trivial changes to the [OpenTelemetry Specification](https://github.com/open-telemetry/opentelemetry-specification).
+* Non-trivial changes to the [OpenTelemetry Semantic Conventions](https://github.com/open-telemetry/semantic-conventions).
+  * Non-trivial being: introducing new conventions, forming a new SIG around a subject, topic or technology and stabilization efforts.
 * A new SIG being formed.
 * An existing SIG taking on new work which will affect the OpenTelemetry project as a whole, and will need review from the broader community.
 
@@ -35,4 +40,4 @@ The project lifecycle is as follows:
 * If a project is approved, the pull request is merged. The project is then added 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 working group is no longer meeting, the project document is moved to the [completed projects](projects/completed-projects/) folder.

projects/llm-semconv.md

@@ -46,6 +46,7 @@ who will benefit from these semantic conventions.
 - @nirga
 - @sudivate
 - @cartermp
+- @gyliu513
 - *Positions open for more engineers*
 
 **Maintainers:**
@@ -78,4 +79,4 @@ Alternating weekly meetings to accommodate different time zones:
 
 ## Project Board
 
-To be established post-approval.
+To be established post-approval.