open-telemetry / open-telemetry/opentelemetry-cpp

[ADMIN] CONTRIBUTORS WELCOME

Open
#3,068 6 comments 0 reactions 1 assignee View on GitHub

@marcalff is already working on this.

Since Jan 27, 2025.

good first issue help wanted
Dominant language
C++
Stars
1.4k
Forks
632
Avg merge
1d 13h
Merged PRs (30d)
75

Description

0. START HERE

This issue lists areas that are good entry points to start contributing to opentelemetry-cpp.

If an item is listed here, it is by definition open to everyone, so no need to ask "Can I work on this ?": yes, you can.

[!CAUTION]
To avoid duplicate work, make sure to check existing PR, maybe this is in progress already.

When considering to work on a PR, make sure to check is the issue is linked to existing PRs first, to see if someone else is working on this area.

Consider to comment, on the issue, that you intend to work on it, as a courtesy to others. This will not make the issue exclusively reserved to you (famous last words: "I am working on this"), but serves as a heads up to prevent overlap.

When posting a new PR, make sure to add Fixes #ISSUE_NUMBER in the description, so the PR will automatically link with the issue by github.

In all cases, this is not about competition, but cooperation: consider to make comments on existing PRs if you see something you would have done differently (and say why).

We do not assign issues, so no need to ask, you can file a PR directly.

For each issue, see the issue comments for details.

1. Functional

Typically, features touching a functional area requires to dive into the code, but do not need changes in the infrastructure, like CI, workflows, compilers, platforms, makefiles ...
This is a good opportunity to learn the C++ code itself. The size of the code affected varies by feature.

1.1 All signals

Typically, changes affecting all signals at once are using the same pattern, applied everywhere.
The change is limited in scope, but touches multiple parts.
This is a good opportunity to learn how to apply design or coding pattern to an existing code base.

  • TODO: find more easy issues
1.2 Entities
  • #3652
1.3 Resource detection
  • TODO: find more easy issues
1.3 Trace signal
  • TODO: find more easy issues
1.4 Metrics signal

Typically, changes affecting the metrics signal are more involved on the functional part (time series, aggregation).
This is a good opportunity to understand in depth a component, with clear boundaries.

  • TODO: find more easy issues
1.5 Logs signal
  • TODO: find more easy issues
1.6 Prometheus exporter

Please check https://github.com/open-telemetry/opentelemetry-specification/issues/4805, see the following comment, and fix gaps to the specifications:

  • Version and format
  • Host
  • Port
  • default_aggregation
  • with_resource_constant_labels
  • translation_strategy
  • content_negotiation
  • interactions with translation strategy
1.7 Specific areas

Typically, features touching a specific area do not require to understand the whole code base, but only a well defined subset.
This is a good opportunity to learn the development process (git, PR, review, merge) as well as the affected code.

  • #2489

2. Code health

This area requires to change CI/CD scripts to improve the build process.
This is a very good opportunity to learn the github CI workflow, to implement new tooling.

2.1 Clang-tidy

Iterative changes, to expand coverage to the entire code base.

  • #2053
2.2 Doxygen
  • #3913

3. Test coverage

This area is a very good opportunity to learn docker to execute tests in a container environment.

  • #454

4. Documentation

This is internal documentation, for maintainers.
We need to document internal processes (like, how to do a release, an upgrade, a deprecation, ...),
as well as feature design (explain how xyz works) at high level, to understand the code base.

  • #2678

5. Major work

Some areas in opentelemetry-cpp need major work, and contributions are welcome here as well.

A couple of things to keep in mind:

  • These are definitively not "good first issue" items, you should have contributed already to opentelemetry-cpp (to be familiar with the process and tooling) and have some experience to be effective.
  • Not every technical aspects are defined yet, a good part of the work will be to propose what needs to be done first.
  • Maintainers are here to help and facilitate this, and will provide guidance.
  • Consider to join the community meetings to discuss specific areas.
5.1 Binary packages

To be able to ship binary packages for opentelemetry-cpp, a lot of preliminary work needs to happen

  • Define how shared libraries are to be versioned, to support compatibility with ABI versions and SDK versions
    • #3110
  • Implement tooling to verify shared libraries compatibility
    • #1996
  • Reduce technical dependencies in the code base
    • #1429
  • Define packages scope
    • #2682
5.2 Full Windows support

To instrument an application using only opentelemetry-cpp api, the following issue needs to be resolved for Windows:

6. Complete specification coverage

6.1. spec-compliance-matrix

The opentelemetry-specification keeps a compliance matrix listing the status for the cpp implementation.

See https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix/cpp.yaml

This matrix gets out of date and needs regular reviews.

Some items might be already implemented, but are not documented as done.
Some items might be missing in opentelemetry-cpp.

Please ping maintainers (by commenting on this issue) if you find out of date entries.

6.2. declarative configuration matrix

The declarative configuration repository keeps a compliance matrix listing the status for the cpp implementation.

See https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema/meta_schema_language_cpp.yaml

How to find remaining items:

[malff@malff-desktop schema]$ pwd
/home/malff/CODE/MY_GITHUB/opentelemetry-configuration/schema
[malff@malff-desktop schema]$ yq '.typeSupportStatuses[] | select(.status == "not_implemented") | .type' meta_schema_language_cpp.yaml 
AlwaysRecordSampler
IdGenerator
RandomIdGenerator
ExperimentalEventToSpanEventBridgeLogRecordProcessor
ExperimentalJaegerRemoteSampler
ExperimentalViewMatchingMode

Remaining work:

  • #4155

7. Too late

Fixed already:

  • #3073
  • #2453
  • #3091
  • #2250
  • #74
  • #3138
  • #2297
  • #2570
  • #2208
  • #2054
  • #2049
  • #1631
  • #3201
  • #3193
  • #2641
  • #1391
  • #3230
  • #3515
  • #3545
  • #3548
  • #3546
  • #3303
  • #1647
  • #3817
  • #3867
  • #3915
  • #2689
  • #2283
  • #2667
  • #3914
  • #4130
  • #3916
  • #3292
  • #4028
  • #4409
  • #4419
  • #4414
  • #4413
  • #4195
  • #4419
  • #4411

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.