Contributing Overview - OpenTelemetry Rust

The OpenTelemetry Rust community welcomes contributions from developers of all experience levels. Whether you’re fixing bugs, adding features, or improving documentation, your contributions help make OpenTelemetry better for everyone.

Community Meetings

The Rust special interest group (SIG) meets on alternating weeks between Tuesday at 9:00 AM PT and Wednesday at 8:00 AM PT. The meeting is subject to change depending on contributors’ availability.

Join the Meeting

Check the OpenTelemetry community calendar for specific dates and Zoom meeting links. Look for “OTel Rust SIG”.

Meeting Notes

View and contribute to our public meeting notes on Google Docs.

Slack Channel

Join the conversation on CNCF Slack in the #otel-rust channel.

The meeting is open for all to join. We invite everyone to participate, regardless of your experience level. Whether you’re a seasoned OpenTelemetry developer, just starting your journey, or simply curious about the work we do, you’re more than welcome to participate!

Community Membership

Anyone can contribute, but there are benefits to becoming an official member of the community. Learn about the different roles:

Member - Active contributors who have made multiple contributions
Approver - Experienced contributors who can review and approve changes
Maintainer - Core team members with full repository access

Current Maintainers

Current Approvers

Anton Grübel, Baz
Björn Antonsson, Datadog
Scott Gerring, Datadog
Shaun Cox, Microsoft

Pull Requests

Before You Start

If you’d like to work on something that isn’t already tracked as an issue — whether it’s a new feature, enhancement, or significant refactor — please create an issue first and describe your proposal. This gives maintainers a chance to provide feedback on the approach before you invest significant time, and helps avoid situations where a PR doesn’t align with the project’s direction. For bug fixes or small improvements to existing functionality, opening a PR directly is fine.

Getting Oriented

If you’re new to the codebase, these documentation resources will help:

Architecture overview — workspace structure, API/SDK separation, and crate responsibilities
Signal-specific design docs: traces, metrics, logs
Architectural decision records — context behind past design choices
Library guidelines from the OpenTelemetry specification

Prerequisites

The opentelemetry-otlp crate uses gRPC + Protocol Buffers. You’ll need protoc version 3.15 or newer:

export PROTOC=$(which protoc)

If building from source, you’ll also need:

protoc
cmake
llvm (with LIBCLANG_PATH environment variable pointing to the bin directory)

Submitting Changes

Clone the repository with submodules:

git clone --recurse-submodule https://github.com/open-telemetry/opentelemetry-rust

Add your fork as a remote:

git remote add <YOUR_FORK> [email protected]:<YOUR_GITHUB_USERNAME>/opentelemetry-rust

Create a branch, make changes, and push:

git checkout -b <YOUR_BRANCH_NAME>
# edit files
git add -p
git commit
git push <YOUR_FORK> <YOUR_BRANCH_NAME>

It is recommended to run the pre-commit script to catch any issues locally.

PR Guidelines

Your pull request should follow the conventional commits standard. This ensures that when the PR is squashed into main, the resulting commit message is consistent and makes changelog generation easier. Best practices:

If the PR is not ready for review, put [WIP] in the title or mark it as draft
Make sure the CLA is signed and all required CI checks pass
Submit small, focused PRs addressing a single concern/issue
Make sure the PR title reflects the contribution
Write a summary that helps understand the change
Include usage examples in the summary, where applicable
Include benchmarks (before/after) for performance enhancements

PR Size and Scope

Keep PRs under 500 lines (excluding Cargo.lock and generated code) to allow thorough and timely reviews.

If your change is larger, consider breaking it into incremental PRs:

First PR: Introduce new types, traits, or structural scaffolding
Follow-up PRs: Add the implementation, split further if needed
Final PR: Wire everything together and update documentation

For changes that span multiple signals (traces, metrics, logs), consider starting with a PR that targets just one signal. This lets maintainers review the approach on a smaller surface area before you replicate it across all three.

Refactoring must be in its own PR with no behavior changes. Mixing refactoring with new functionality makes it difficult for reviewers to verify correctness.

Getting PRs Merged

A PR is considered ready to merge when:

It has received approval from Approvers or Maintainers
Major feedback is resolved

Any Maintainer can merge the PR once it is ready. Some PRs may not be merged immediately if the repo is in the process of a release, or if maintainers decide to wait for additional approvals on changes affecting multiple areas.

Issue Management

Filing Issues

When creating a new issue, please use one of the provided issue templates (Bug Report or Feature Request). The templates automatically apply triage labels so maintainers can find and review new issues. Avoid creating blank issues, as they won’t have the correct labels and may be overlooked.

Triage Labels

Every new issue starts with triage:todo. Maintainers review these and apply:

triage:accepted — the issue has been reviewed and is ready to be worked on
triage:needmoreinfo — the issue needs clarification from the reporter

Don’t start work on an issue that hasn’t been triaged. Wait for triage:accepted or ask in the issue if you’re interested.

Finding Work

good first issue — scoped issues suitable for newcomers to the codebase
help wanted — issues where maintainers welcome contributions and will provide extra guidance

Area Labels

Label	Area
`A-trace`	Tracing signal
`A-metrics`	Metrics signal
`A-log`	Logs signal
`A-common`	Cross-cutting / not signal-specific

Module Labels

Label	Crate
`M-api`	`opentelemetry` (API)
`M-sdk`	`opentelemetry-sdk`
`M-exporter-otlp`	`opentelemetry-otlp`
`M-exporter-prometheus`	`opentelemetry-prometheus`
`M-exporter-zipkin`	`opentelemetry-zipkin`

Priority Labels

Label	Meaning
`priority:p0`	Critical stop-the-world issues. Drop everything.
`priority:p1`	High priority — should be addressed soon
`priority:p2`	Medium priority
`priority:p3`	Low priority — nice to have

Version Labels

These labels are applied to PRs to indicate their semver impact:

Label	Impact
`version:breaking`	Breaking change (major version bump)
`version:minor`	New functionality (minor version bump)
`version:patch`	Bug fix (patch version bump)

Development Guidelines

Design Philosophy

OpenTelemetry Rust follows the OpenTelemetry specification, with a focus on: Capabilities over structure compliance - Contributions should provide functionality and behavior that conforms to the specification, but the interface and structure is flexible. It’s preferable to follow Rust idioms rather than conform to specific API names or argument patterns in the spec.

Error Handling

The OpenTelemetry Rust SDK has two ways to handle errors:

When errors are not allowed to return, call the global error handler
Otherwise, return the errors

All errors use the opentelemetry::Error type:

Trace module errors: wrapped in opentelemetry::trace::TraceError
Metrics module errors: wrapped in opentelemetry::metrics::MetricError
Logs module errors: wrapped in opentelemetry::logs::LogsError

For custom exporters, it’s recommended to wrap all errors into a crate-level error type and implement the ExporterError trait.

Configuration Priority

OpenTelemetry supports multiple configuration methods with the following priority:

Environment variables (highest priority)
Compile-time configurations in source code

Experimental Features

Use the otel_unstable feature flag for experimental specification features:

#[cfg(feature = "otel_unstable")]
{
    // Your feature implementation
}

Regularly review and remove the otel_unstable flag once features become stable.

Optional Features

Optional features should follow the naming convention <signal>_<feature_name>. Examples:

Signal features: logs, traces, metrics
Runtime features: rt-tokio, rt-tokio-current-thread

Testing and Quality

Code Quality

Run these commands before submitting:

# Catch common mistakes and improve code
cargo clippy --all

# Format code
cargo fmt

Testing

# Run all tests
cargo test --all

# Run benchmarks
cargo bench

FAQ

Where should I put third party propagators/exporters?

The specification classifies propagators into three categories: fully open standards, platform-specific standards, and proprietary headers. Only fully open standards should live as independent crates in this repository. For more details, see this PR discussion.

Community

​Community Meetings

Join the Meeting

Meeting Notes

Slack Channel

​Community Membership

​Current Maintainers

​Current Approvers

​Pull Requests

​Before You Start

​Getting Oriented

​Prerequisites

​Submitting Changes

​PR Guidelines

​PR Size and Scope

​Getting PRs Merged

​Issue Management

​Filing Issues

​Triage Labels

​Finding Work

​Area Labels

​Module Labels

​Priority Labels

​Version Labels

​Development Guidelines

​Design Philosophy

​Error Handling

​Configuration Priority

​Experimental Features

​Optional Features

​Testing and Quality

​Code Quality

​Testing

​FAQ

​Where should I put third party propagators/exporters?

Build docs developers (and LLMs) love

Community Meetings

Community Membership

Current Maintainers

Current Approvers

Pull Requests

Before You Start

Getting Oriented

Prerequisites

Submitting Changes

PR Guidelines

PR Size and Scope

Getting PRs Merged

Issue Management

Filing Issues

Triage Labels

Finding Work

Area Labels

Module Labels

Priority Labels

Version Labels

Development Guidelines

Design Philosophy

Error Handling

Configuration Priority

Experimental Features

Optional Features

Testing and Quality

Code Quality

Testing

FAQ

Where should I put third party propagators/exporters?