Skip to content

Latest commit

 

History

History
117 lines (81 loc) · 3.64 KB

CONTRIBUTING.md

File metadata and controls

117 lines (81 loc) · 3.64 KB
Raw

Contributing to opentelemetry-rust

The Rust special interest group (SIG) meets regularly. See the OpenTelemetry community repo for information on this and other language SIGs.

See the public meeting notes for a summary description of past meetings. To request edit access, join the meeting or get in touch on Gitter.

Pull Requests

Prerequisites

Crate opentelemetry-otlp uses gRPC. So you will need the following to build:

  • protoc
  • cmake
  • llvm (and LIBCLANG_PATH environment variable pointing to the bin directory of LLVM install)

How to Send Pull Requests

Everyone is welcome to contribute code to opentelemetry-rust via GitHub pull requests (PRs).

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

Enter the newly created directory and add your fork as a new remote:

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

Check out a new branch, make modifications, run linters and tests, and push the branch to your fork:

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

Open a pull request against the main opentelemetry-rust repo.

How to Receive Comments

  • If the PR is not ready for review, please put [WIP] in the title, tag it as work-in-progress, or mark it as draft.
  • Make sure CLA is signed and CI is clear.

How to Get PRs Merged

A PR is considered to be ready to merge when:

  • It has received approval from Collaborators/Maintainers.
  • Major feedback is resolved.

Any Collaborator/Maintainer can merge the PR once it is ready to merge.

Design Choices

As with other OpenTelemetry clients, opentelemetry-rust follows the opentelemetry-specification.

It's especially valuable to read through the library guidelines.

Focus on Capabilities, Not Structure Compliance

OpenTelemetry is an evolving specification, one where the desires and use cases are clear, but the method to satisfy those uses cases are not.

As such, Contributions should provide functionality and behavior that conforms to the specification, but the interface and structure is flexible.

It is preferable to have contributions follow the idioms of the language rather than conform to specific API names or argument patterns in the spec.

For a deeper discussion, see: open-telemetry/opentelemetry-specification#165

Style Guide

  • Run cargo clippy --all - this will catch common mistakes and improve your Rust code
  • Run cargo fmt - this will find and fix code formatting issues.

Testing and Benchmarking

  • Run cargo test --all - this will execute code and doc tests for all projects in this workspace.
  • Run cargo bench - this will run benchmarks to show performance regressions

Approvers and Maintainers

See the code owners file.

Become an Approver or a Maintainer

See the community membership document in OpenTelemetry community repo.