> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/open-telemetry/opentelemetry-rust/llms.txt
> Use this file to discover all available pages before exploring further.
# Contributing Overview
> Learn how to contribute to OpenTelemetry Rust, including pull request guidelines, issue management, and community participation.
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.
Check the OpenTelemetry community calendar for specific dates and Zoom meeting links. Look for "OTel Rust SIG".
View and contribute to our public meeting notes on Google Docs.
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**](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#member) - Active contributors who have made multiple contributions
* [**Approver**](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#approver) - Experienced contributors who can review and approve changes
* [**Maintainer**](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer) - Core team members with full repository access
### Current Maintainers
* [Cijo Thomas](https://github.com/cijothomas), Microsoft
* [Harold Dost](https://github.com/hdost)
* [Lalit Kumar Bhasin](https://github.com/lalitb), Microsoft
* [Utkarsh Umesan Pillai](https://github.com/utpilla), Microsoft
* [Zhongyang Wu](https://github.com/TommyCpp)
### Current Approvers
* [Anton Grübel](https://github.com/gruebel), Baz
* [Björn Antonsson](https://github.com/bantonsson), Datadog
* [Scott Gerring](https://github.com/scottgerring), Datadog
* [Shaun Cox](https://github.com/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](https://github.com/open-telemetry/opentelemetry-rust/issues/new) 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](https://github.com/open-telemetry/opentelemetry-rust/blob/main/docs/design/architecture.md) — workspace structure, API/SDK separation, and crate responsibilities
* Signal-specific design docs: [traces](https://github.com/open-telemetry/opentelemetry-rust/blob/main/docs/design/traces.md), [metrics](https://github.com/open-telemetry/opentelemetry-rust/blob/main/docs/design/metrics.md), [logs](https://github.com/open-telemetry/opentelemetry-rust/blob/main/docs/design/logs.md)
* [Architectural decision records](https://github.com/open-telemetry/opentelemetry-rust/tree/main/docs/adr/) — context behind past design choices
* [Library guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/library-guidelines.md) from the OpenTelemetry specification
### Prerequisites
The `opentelemetry-otlp` crate uses gRPC + Protocol Buffers. You'll need protoc version 3.15 or newer:
```bash theme={null}
export PROTOC=$(which protoc)
```
If building from source, you'll also need:
* [protoc](https://github.com/protocolbuffers/protobuf)
* [cmake](https://cmake.org)
* [llvm](https://releases.llvm.org/download.html) (with `LIBCLANG_PATH` environment variable pointing to the `bin` directory)
### Submitting Changes
Clone the repository with submodules:
```bash theme={null}
git clone --recurse-submodule https://github.com/open-telemetry/opentelemetry-rust
```
Add your fork as a remote:
```bash theme={null}
git remote add git@github.com:/opentelemetry-rust
```
Create a branch, make changes, and push:
```bash theme={null}
git checkout -b
# edit files
git add -p
git commit
git push
```
It is recommended to run the [pre-commit script](https://github.com/open-telemetry/opentelemetry-rust/blob/main/scripts/precommit.sh) to catch any issues locally.
### PR Guidelines
Your pull request should follow the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) 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`](https://github.blog/2019-02-14-introducing-draft-pull-requests/)
* 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:
1. **First PR**: Introduce new types, traits, or structural scaffolding
2. **Follow-up PRs**: Add the implementation, split further if needed
3. **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](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#approver) or [Maintainers](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer)
* 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](https://github.com/open-telemetry/opentelemetry-rust/issues/new/choose) (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](https://github.com/open-telemetry/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:
1. When errors are not allowed to return, call the global error handler
2. 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:
1. Environment variables (highest priority)
2. Compile-time configurations in source code
### Experimental Features
Use the `otel_unstable` feature flag for experimental specification features:
```rust theme={null}
#[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 `_`. Examples:
* Signal features: `logs`, `traces`, `metrics`
* Runtime features: `rt-tokio`, `rt-tokio-current-thread`
## Testing and Quality
### Code Quality
Run these commands before submitting:
```bash theme={null}
# Catch common mistakes and improve code
cargo clippy --all
# Format code
cargo fmt
```
### Testing
```bash theme={null}
# 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](https://github.com/open-telemetry/opentelemetry-specification/pull/1144).