[ADMIN] CONTRIBUTORS WELCOME

[marcalff]

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

• Implement entity propagation #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 open-telemetry/opentelemetry-specification#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.

• [BUILD] Enable SSL for curl in bazel build environment #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.

• [Code health] clang-tidy cleanup #2053

2.2 Doxygen

• [DOC] Publish the doxygen doc #3913

3. Test coverage

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

• Test example code in CI #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.

• [DOC] Upgrade for each dependency is hard to maintain #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
  • Please add number version in SONAMEs. #3110
• Implement tooling to verify shared libraries compatibility
  • Tool to detect API/ABI non-compliant changes, and integrate with CI. #1996
• Reduce technical dependencies in the code base
  • Move implementation from SDK header files to SDK *.cc #1429
• Define packages scope
  • Binary releases and package management #2682

5.2 Full Windows support

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

• See comments: Opentelemetry API singletons (TraceProvider etc.) do not play well in shared library uses that hide symbol visibility #1520 (comment)
• Header only singletons are not working properly for Windows #2534
• Exporting spans from inside DLL on Windows does not work. #3176

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:

• [CONFIGURATION] File configuration - EventToSpanEventBridge #4155

7. Too late

Fixed already:

• [EXPORTER] exporter endpoint doesn't support ipv6 #3073
• [EXPORTER] Add optional configuration for prometheus exporter #2453
• ElasticSearch Exporter does not follow ECS guidelines and logging reference #3091
• Log SSL Connection Information #2250
• W3C TraceContext compliance #74
• URL parser throws an exception #3138
• [CI] Add a C++ static code analyser in the build #2297
• [EXPORTER] optimize OTLP HTTP compression #2570
• [TEST] Functional tests for OTLP GRPC MTLS export #2208
• [Code health] include-what-you-use cleanup #2054
• Support handling Retryable error for OTLP exporter (OTLP/gRPC and OTLP/HTTP) #2049
• [SDK] Support OTEL_SDK_DISABLED environment variable #1631
• Support exporting event_name using OTLP Exporter #3201
• Deprecate event logger #3193
• [SDK] Add simple scope configuration to Tracer, Meter, Logger #2641
• [Metrics SDK] Add support for Exponential Histogram Aggregation #1391
• [Metrics SDK] Optimize Thread Usage in PeriodicExportingMetricReader #3230
• Support periodic exporting MetricReader config from env vars #3515
• [SDK] ParentBasedSampler is missing parameters #3545
• [SDK] Implement resource detectors #3548
• [SDK] MetricFilter needs a new AttributeProcessor to handle IncludeExclude #3546
• SDK Implement collection limits #3303
• [CI] Add a doxygen build #1647
• [feature request] Support the environment variable propagation spec in cpp #3817
• [SDK] Swap Tracer/Meter/LoggerConfig disabled for enabled #3867
• [CONFIGURATION] File configuration - Tracer/Meter/Logger config #3915
• Update the parameter names in LoggerProvider::GetLogger #2689
• Support for "random trace id" flag in trace context #2283
• [API] Support for Logger::Enabled() is incomplete #2667
• [CONFIGURATION] File configuration - composable samplers #3914
• [CONFIGURATION] File configuration - ExperimentalLoggerConfig #4130
• [CONFIGURATION] File configuration - resource detectors #3916
• [Metrics SDK] Make cardinality limit configurable #3292
• [SDK] Implement ComposableSampler #4028
• [CONFIGURATION] Implement ComposableSampler Extensions #4409
• [CONFIGURATION] Resource detector extension example #4419
• [RESOURCE DETECTOR] Service resource detector #4414
• [RESOURCE DETECTOR] Host resource detector #4413
• [CODE HEALTH] clang-tidy misc-override-with-different-visibility warnings #4195
• [CONFIGURATION] Resource detector extension example #4419
• [CONFIGURATION] Complete resource detection support in SdkBuilder #4411

[github-actions]

This issue is available for anyone to work on. Make sure to reference this issue in your pull request.
✨ Thank you for your contribution! ✨

[brown-eric]

Hey, how can I help on this issue?

[ThomsonTan]

Hey, how can I help on this issue?

Could you please add comments on which issue you are interested? We can assign it to you to look into.

[brown-eric]

Which do you recommend? I'm new to this and would like to contribute for the first time! I have an assignment to do so and would love to be able to help this project #a little bit

[lalitb]

@marcalff Can we add these two for metrics under functional category.

#3292
#3230

[johnmichaelll238-cloud]

Hi, please can I work on this too? I'd really like to help out on this matter