OpenTelemetry

Description: Help to drive our project board for OpenTelemetry PHP. This includes validating spec compliance and writing PHP code to implement some of these features

Maintenance of a stable Go library often involves value-judgement calls regarding what changes can impact downstream consumers. While some existing tooling like apidiff can go some way towards preventing breakage, these tools work purely in terms of API-level breakage such as changing the type of a symbol. Inspired by tooling in other language ecosystems such as Rust this proposal sets out to build a tool that can give statistical information about the impact of any change on downstream consumers by running the build pipelines and test suites of dependents before and after a particular change. This would empower maintainers to make better informed choices about changes and foster an ecosystem. We think this is specially important for the OpenTelemetry project since the OpenTelemetry Go modules and the OpenTelemetry Collector modules are foundational modules used within the CNCF on other projects (e.g Kubernetes, Jaeger) as well as outside of it. The intent is to build a tool that could be used as well by other CNCF projects since Go is the *lingua franca* of the foundation, enabling all projects to have a flourishing ecosystem. - Expected Outcome: We would like to have a tool written in Go that is able to (i) gather all publicly-listed dependencies of a module, (ii) safely run the test suite of dependencies for a given version of the code and (iii) compare two test suites and provide a statistical summary of the differences between the two to help in decision-making.

Various special interest groups (a.k.a. SIGs) in the OpenTelemetry project run surveys to understand the experience of the end-users better. To run surveys efficiently, SIG End-user provides guidelines and assistance to people running surveys. In the past, SIG End-user focused on providing guidelines around survey design. Now we would like to move forward and cover survey data analysis and communication findings. Expected Outcome: The mentee in this project will describe a step-by-step survey data analysis process and tools that OTel contributors without deep data analytics knowledge can leverage to analyze their survey data – from cleaning and coding of data, through descriptive statistics, cross-tabulation, to visualization. In addition, the mentee will come up with suggestions on how to improve existing and/or propose new ways to communicate survey findings from surveys to the OpenTelemetry community. [Bonus] The mentee might also execute one survey to test out the guidelines.

<p>The [OpenTelemetry Go Compile Instrumentation](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) project provides `otelc`, a compile-time auto-instrumentation tool for Go applications. It injects OpenTelemetry instrumentation during the Go build process without requiring manual source-code changes in the target application. As the project moves toward its v1.0 release and continues feature-parity work with mature compile-time instrumentation efforts such as [Orchestrion](https://github.com/DataDog/orchestrion) and [Loongsuite](https://github.com/alibaba/loongsuite-go-agent), the next phase is to broaden real-world library coverage while hardening the tooling and contributor workflow needed to maintain those integrations over time. This mentorship focuses on adding several mentor-approved integrations from the project roadmap and backlog, such as messaging, database/cache, logging, Kubernetes client, or GenAI SDK libraries, while improving `otelc` whenever the integration work exposes gaps in rule authoring, hook implementation, testing, or debugging. The mentee will also document the science behind compile-time instrumentation: how Go symbols and versions are matched, how hooks are injected, how OpenTelemetry semantic conventions are applied, and how compatibility is verified across library releases.</p><p><br></p><p>Expected Outcome:</p><p> - Add `otelc` instrumentation support for 3-4 widely used Go libraries selected with mentors from the project roadmap/backlog, depending on complexity and project priorities.</p><p>&nbsp;- For each new integration, implement instrumentation rules and hook code, define supported version ranges, and follow the relevant OpenTelemetry semantic conventions.</p><p>&nbsp;- Add meaningful unit, integration, and/or end-to-end tests that verify the instrumented application builds and emits the expected telemetry.</p><p>&nbsp;- Improve the instrumentation tooling or contributor workflow as needed during the work, for example rule validation, hook scaffolding, latest-library compatibility checks, integration layout, or debugging output.</p><p>&nbsp;- Write documentation, examples, and demos that explain how to use the new integrations and how future contributors can build similar ones.</p><p><br></p>

<p>The [Ecosystem Explorer](<a href="https://explorer.opentelemetry.io" rel="noopener noreferrer" target="_blank">https://explorer.opentelemetry.io</a>) helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>User Interviews Report: Summarized findings from 3-5 user interviews covering different user types and key tasks</li><li>Competitive Analysis Report: Findings from reviewing 2-3 similar tools (e.g., package registries, API documentation sites) on how they present component information</li><li>Information Architecture Recommendations: Proposed structure for presenting a specific type of component data (e.g., "instrumentation" or "collector components")</li><li>Wireframes/mockups (stretch goal): Visual concepts for key user flows</li></ul>