Merge branch 'main' into inahga/fix-aggregation-validation

.cspell.json

@@ -25,13 +25,33 @@
     // these are words that are always correct and can be thought of as our
     // workspace dictionary.
     "words": [
+        "actix",
+        "appender",
+        "appenders",
+        "Bhasin",
+        "Cijo",
+        "codecov",
         "deque",
+        "Dirkjan",
         "hasher",
+        "isahc",
+        "Isobel",
+        "jaegertracing",
+        "Kühle",
+        "Kumar",
+        "Lalit",
         "msrv",
+        "Ochtman",
+        "openetelemetry",
         "opentelemetry",
         "OTLP",
+        "protoc",
         "quantile",
+        "Redelmeier",
+        "reqwest",
         "rustc",
+        "Tescher",
+        "Zhongyang",
         "zipkin"
     ],
     "enabledLanguageIds": [

.github/ISSUE_TEMPLATE/BUG-REPORT.yml

@@ -0,0 +1,51 @@
+name: Bug Report
+description: File a bug report
+title: "[Bug]: "
+labels: ["bug", "triage:todo"]
+projects: ["open-telemetry/opentelemetry-rust"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+      value: "A bug happened!"
+    validations:
+      required: true
+  - type: textarea
+    id: api-version
+    attributes:
+      label: API Version
+      description: What version of the OpenTelemetry API are you using?
+      placeholder: 0.x, 1.x, etc.
+    validations:
+      required: true
+  - type: textarea
+    id: sdk-version
+    attributes:
+      label: SDK Version
+      description: What version of the OpenTelemetry SDK are you using?
+      placeholder: 0.x, 1.x, etc.
+    validations:
+      required: true
+  - type: dropdown
+    id: browsers
+    attributes:
+      label: What Exporters are you seeing the problem on?
+      multiple: true
+      options:
+        - OTLP
+        - Zipkin
+        - Jaeger (Deprecated)
+        - N/A
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      render: shell

.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml

@@ -0,0 +1,48 @@
+---
+name: "Feature Request"
+description: Request a feature for the OpenTelemetry Rust implementation.
+title: "[Feature]: "
+labels: ["enhancement", "triage:todo"]
+projects: ["open-telemetry/opentelemetry-rust"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for using our library and trying to make it better!
+
+        Before opening a feature request against this repo, consider whether the feature
+        should/could be implemented in the [other OpenTelemetry client
+        libraries](https://github.com/open-telemetry/). If so, please [open an issue on
+        opentelemetry-specification](https://github.com/open-telemetry/opentelemetry-specification/issues/new) first.
+  - type: textarea
+    id: related-problem
+    attributes:
+      label: Related Problems?
+      description: Is your feature request related to a problem? If so, provide a concise description of the problem.
+      placeholder: Include the Issue ID from this or other repos.
+    validations:
+      required: false
+  - type: textarea
+    id: solution
+    attributes:
+      label: "Describe the solution you'd like:"
+      description: What do you want to happen instead? What is the expected behavior?
+      placeholder: I'd like the api to ...
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Considered Alternatives
+      description: Which alternative solutions or features have you considered?
+      placeholder: Some potential solutions
+    validations:
+      required: false
+  - type: textarea
+    id: additional-context
+    attributes:
+      label: Additional Context
+      description: Add any other context about the feature request here.
+      placeholder: Some related requests in other project or upstream spec proposals.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+contact_links:
+  - name: GitHub Discussions
+    url: https://github.com/open-telemetry/opentelemetry-rust/discussions/new/choose
+    about: Please ask questions here.
+  - name: Slack
+    url: https://cloud-native.slack.com/archives/C03GDP0H023
+    about: Or the `#otel-rust` channel in the CNCF Slack instance. (Not terribly responsive.)
+  - name: "⚠️ Report a security vulnerability"
+    url: "https://github.com/open-telemetry/opentelemetry-rust/security/advisories/new"
+    about: "Report a security vulnerability."
+

.github/workflows/ci.yml

@@ -6,6 +6,8 @@ on:
   push:
     branches:
     - main
+    paths-ignore:
+    - '**.md'
 jobs:
   test:
     strategy:

.gitignore

@@ -3,3 +3,4 @@
 */target/
 **/*.rs.bk
 Cargo.lock
+/.idea/

CODEOWNERS

@@ -1,5 +1,7 @@
-# Code owners file.
-# This file controls who is tagged for review for any given pull request.
+# Code owners file
 
-# For anything not explicitly taken by someone else:
-*  @open-telemetry/rust-approvers
+## This file controls who is tagged for review for any given pull request.
+
+## For anything not explicitly taken by someone else:
+
+* @open-telemetry/rust-approvers

CONTRIBUTING.md

@@ -1,21 +1,27 @@
 # Contributing to opentelemetry-rust
 
-The Rust special interest group (SIG) meets regularly. See the
-OpenTelemetry
-[community](https://github.com/open-telemetry/community#implementation-sigs)
-repo for information on this and other language SIGs.
-
-See the [public meeting
-notes](https://docs.google.com/document/d/1tGKuCsSnyT2McDncVJrMgg74_z8V06riWZa0Sr79I_4/edit)
-for a summary description of past meetings. To request edit access,
-join the meeting or get in touch on
+The Rust special interest group (SIG) meets weekly on Tuesdays at 9 AM Pacific
+Time. The meeting is subject to change depending on contributors'
+availability. Check the [OpenTelemetry community
+calendar](https://calendar.google.com/calendar/embed?src=google.com_b79e3e90j7bbsa2n2p5an5lf60%40group.calendar.google.com)
+for specific dates and for Zoom meeting links. "OTel Rust SIG" is the name of
+meeting for this group.
+
+Meeting notes are available as a public [Google
+doc](https://docs.google.com/document/d/1tGKuCsSnyT2McDncVJrMgg74_z8V06riWZa0Sr79I_4/edit).
+If you have trouble accessing the doc, please get in touch on
 [Slack](https://cloud-native.slack.com/archives/C03GDP0H023).
 
+The meeting is open for all to join. We invite everyone to join our meeting,
+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!
+
 ## Pull Requests
 
 ### Prerequisites
 
-Crate `opentelemetry-otlp` uses gRPC + Protocol Buffers.<br>
+Crate `opentelemetry-otlp` uses gRPC + Protocol Buffers.
 You can provide the protocol compiler protoc path programmatically (only works with tonic) or build it from source
 
 ```sh
@@ -34,13 +40,13 @@ Everyone is welcome to contribute code to `opentelemetry-rust` via
 GitHub pull requests (PRs).
 
 ```sh
-$ git clone --recurse-submodule https://github.com/open-telemetry/opentelemetry-rust
+git clone --recurse-submodule https://github.com/open-telemetry/opentelemetry-rust
 ```
 
 Enter the newly created directory and add your fork as a new remote:
 
 ```sh
-$ git remote add <YOUR_FORK> git@github.com:<YOUR_GITHUB_USERNAME>/opentelemetry-rust
+git remote add <YOUR_FORK> git@github.com:<YOUR_GITHUB_USERNAME>/opentelemetry-rust
 ```
 
 Check out a new branch, make modifications, run linters and tests, and
@@ -64,20 +70,32 @@ the repo to catch any issues locally.
 
 ### 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`](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
-* Make sure CLA is signed and CI is clear.
+- If the PR is not ready for review, please put `[WIP]` in the title or mark it
+  as [`draft`](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
+- Make sure CLA is signed and all required CI checks are clear.
+- 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) in the summary, for contributions that are
+  performance enhancements.
 
 ### 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.
+- It has received approval from
+  [Approvers](https://github.com/open-telemetry/community/blob/main/community-membership.md#approver).
+  /
+  [Maintainers](https://github.com/open-telemetry/community/blob/main/community-membership.md#maintainer).
+- Major feedbacks are resolved.
 
-Any Collaborator/Maintainer can merge the PR once it is **ready to
-merge**.
+Any Maintainer can merge the PR once it is **ready to merge**. Note, that some
+PRs may not be merged immediately if the repo is in the process of a release and
+the maintainers decided to defer the PR to the next release train. Also,
+maintainers may decide to wait for more than one approval for certain PRs,
+particularly ones that are affecting multiple areas, or topics that may warrant
+more discussion.
 
 ## Design Choices
 
@@ -102,27 +120,57 @@ language rather than conform to specific API names or argument
 patterns in the spec.
 
 For a deeper discussion, see:
-https://github.com/open-telemetry/opentelemetry-specification/issues/165
+<https://github.com/open-telemetry/opentelemetry-specification/issues/165>
 
 ### Error Handling
-Currently, the Opentelemetry Rust SDK has two ways to handle errors. In the situation where errors are not allowed to return. One should call global error handler to process the errors. Otherwise, one should return the errors. 
 
-The Opentelemetry Rust SDK comes with an error type `openetelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`. 
+Currently, the Opentelemetry Rust SDK has two ways to handle errors. In the situation where errors are not allowed to return. One should call global error handler to process the errors. Otherwise, one should return the errors.
+
+The Opentelemetry Rust SDK comes with an error type `openetelemetry::Error`. For different function, one error has been defined. All error returned by trace module MUST be wrapped in `opentelemetry::trace::TraceError`. All errors returned by metrics module MUST be wrapped in `opentelemetry::metrics::MetricsError`.
+
+For users that want to implement their own exporters. It's RECOMMENDED to wrap all errors from the exporter into a crate-level error type, and implement `ExporterError` trait.
+
+### Priority of configurations
+
+OpenTelemetry supports multiple ways to configure the API, SDK and other components. The priority of configurations is as follows:
+
+- Environment variables
+- Compiling time configurations provided in the source code
+
+### Experimental/Unstable features:
+
+Use `otel_unstable` feature flag for implementation of specification with [experimental](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.27.0/specification/document-status.md) status. This approach ensures clear demarcation and safe integration of new or evolving features. Utilize the following structure:
+
+```rust
+#[cfg(feature = "otel_unstable")]
+{
+    // Your feature implementation
+}
+```
+It's important to regularly review and remove the `otel_unstable` flag from the code once the feature becomes stable. This cleanup process is crucial to maintain the overall code quality and to ensure that stable features are accurately reflected in the main build.
 
-For users that want to implement their own exporters. It's RECOMMENDED to wrap all errors from the exporter into a crate-level error type, and implement `ExporterError` trait.  
+### Optional features:
+
+The potential features include:
+
+- Stable and non-experimental features that compliant to specification, and have a feature flag to minimize compilation size. Example: feature flags for signals (like `logs`, `traces`, `metrics`) and runtimes (`rt-tokio`, `rt-tokio-current-thread`, `rt-async-std`).
+- Stable and non-experimental features, although not part of the specification, are crucial for enhancing the tracing/log crate's functionality or boosting performance. These features are also subject to discussion and approval by the OpenTelemetry Rust Maintainers. An example of such a feature is `logs_level_enabled`.
+
+All such features should adhere to naming convention  `<signal>_<feature_name>`
 
 ## Style Guide
 
-* Run `cargo clippy --all` - this will catch common mistakes and improve
+- Run `cargo clippy --all` - this will catch common mistakes and improve
 your Rust code
-* Run `cargo fmt` - this will find and fix code formatting
+- 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
+- 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 
+- Run `cargo bench` - this will run benchmarks to show performance
+- Run `cargo bench` - this will run benchmarks to show performance
 regressions
 
 ## Approvers and Maintainers
@@ -131,21 +179,21 @@ For GitHub groups see the [code owners](CODEOWNERS) file.
 
 ### Maintainers
 
-* [Dirkjan Ochtman](https://github.com/djc)
+* [Cijo Thomas](https://github.com/cijothomas)
+* [Harold Dost](https://github.com/hdost)
 * [Julian Tescher](https://github.com/jtescher)
 * [Zhongyang Wu](https://github.com/TommyCpp)
 
 ### Approvers
 
-* [Cijo Thomas](https://github.com/cijothomas)
-* [Harold Dost](https://github.com/hdost)
 * [Lalit Kumar Bhasin](https://github.com/lalitb)
 * [Shaun Cox](https://github.com/shaun-cox)
 
 ### Emeritus
 
-* [Jan Kühle](https://github.com/frigus02)
-* [Isobel Redelmeier](https://github.com/iredelmeier)
+- [Dirkjan Ochtman](https://github.com/djc)
+- [Jan Kühle](https://github.com/frigus02)
+- [Isobel Redelmeier](https://github.com/iredelmeier)
 
 ### Become an Approver or a Maintainer
 
@@ -157,5 +205,12 @@ repo](https://github.com/open-telemetry/community/blob/master/community-membersh
 [![contributors](https://contributors-img.web.app/image?repo=open-telemetry/opentelemetry-rust)](https://github.com/open-telemetry/opentelemetry-rust/graphs/contributors)
 
 ## FAQ
+
 ### Where should I put third party propagators/exporters, contrib or standalone crates?
-As of now, the specification classify the propagators into three categories: Fully opened standards, platform-specific standards, proprietary headers. The conclusion is only the fully opened standards should live in SDK packages/repos. So here, only fully opened standards should live as independent crate. For more detail and discussion, see [this pr](https://github.com/open-telemetry/opentelemetry-specification/pull/1144).  
+
+As of now, the specification classify the propagators into three categories:
+Fully opened standards, platform-specific standards, proprietary headers. The
+conclusion is only the fully opened standards should live in SDK packages/repos.
+So here, only fully opened standards should live as independent crate. For more
+detail and discussion, see [this
+pr](https://github.com/open-telemetry/opentelemetry-specification/pull/1144).