[bugfix] Downstep otel to fix freebsd compile issue (#1773)

https://github.com/open-telemetry/opentelemetry-go/issues/4076

vendor/go.opentelemetry.io/otel/CONTRIBUTING.md

@@ -6,7 +6,7 @@ OpenTelemetry
 repo for information on this and other language SIGs.
 
 See the [public meeting
-notes](https://docs.google.com/document/d/1E5e7Ld0NuU1iVvf-42tOBpu2VBBLYnh73GJuITGJTTU/edit)
+notes](https://docs.google.com/document/d/1A63zSWX0x2CyCK_LoNhmQC4rqhLpYXJzXbEPDUQ2n6w/edit#heading=h.9tngw7jdwd6b)
 for a summary description of past meetings. To request edit access,
 join the meeting or get in touch on
 [Slack](https://cloud-native.slack.com/archives/C01NPAXACKT).
@@ -94,58 +94,30 @@ request ID to the entry you added to `CHANGELOG.md`.
 
 ### How to Get PRs Merged
 
-A PR is considered **ready to merge** when:
+A PR is considered to be **ready to merge** when:
 
-* It has received two qualified approvals[^1].
+* It has received two approvals from Collaborators/Maintainers (at
+  different companies). This is not enforced through technical means
+  and a PR may be **ready to merge** with a single approval if the change
+  and its approach have been discussed and consensus reached.
+* Feedback has been addressed.
+* Any substantive changes to your PR will require that you clear any prior
+  Approval reviews, this includes changes resulting from other feedback. Unless
+  the approver explicitly stated that their approval will persist across
+  changes it should be assumed that the PR needs their review again. Other
+  project members (e.g. approvers, maintainers) can help with this if there are
+  any questions or if you forget to clear reviews.
+* It has been open for review for at least one working day. This gives
+  people reasonable time to review.
+* Trivial changes (typo, cosmetic, doc, etc.) do not have to wait for
+  one day and may be merged with a single Maintainer's approval.
+* `CHANGELOG.md` has been updated to reflect what has been
+  added, changed, removed, or fixed.
+* `README.md` has been updated if necessary.
+* Urgent fix can take exception as long as it has been actively
+  communicated.
 
-  This is not enforced through automation, but needs to be validated by the
-  maintainer merging.
-  * The qualified approvals need to be from [Approver]s/[Maintainer]s
-    affiliated with different companies. Two qualified approvals from
-    [Approver]s or [Maintainer]s affiliated with the same company counts as a
-    single qualified approval.
-  * PRs introducing changes that have already been discussed and consensus
-    reached only need one qualified approval. The discussion and resolution
-    needs to be linked to the PR.
-  * Trivial changes[^2] only need one qualified approval.
-
-* All feedback has been addressed.
-  * All PR comments and suggestions are resolved.
-  * All GitHub Pull Request reviews with a status of "Request changes" have
-    been addressed. Another review by the objecting reviewer with a different
-    status can be submitted to clear the original review, or the review can be
-    dismissed by a [Maintainer] when the issues from the original review have
-    been addressed.
-  * Any comments or reviews that cannot be resolved between the PR author and
-    reviewers can be submitted to the community [Approver]s and [Maintainer]s
-    during the weekly SIG meeting. If consensus is reached among the
-    [Approver]s and [Maintainer]s during the SIG meeting the objections to the
-    PR may be dismissed or resolved or the PR closed by a [Maintainer].
-  * Any substantive changes to the PR require existing Approval reviews be
-    cleared unless the approver explicitly states that their approval persists
-    across changes. This includes changes resulting from other feedback.
-    [Approver]s and [Maintainer]s can help in clearing reviews and they should
-    be consulted if there are any questions.
-
-* The PR branch is up to date with the base branch it is merging into.
-  * To ensure this does not block the PR, it should be configured to allow
-    maintainers to update it.
-
-* It has been open for review for at least one working day. This gives people
-  reasonable time to review.
-  * Trivial changes[^2] do not have to wait for one day and may be merged with
-    a single [Maintainer]'s approval.
-
-* All required GitHub workflows have succeeded.
-* Urgent fix can take exception as long as it has been actively communicated
-  among [Maintainer]s.
-
-Any [Maintainer] can merge the PR once the above criteria have been met.
-
-[^1]: A qualified approval is a GitHub Pull Request review with "Approve"
-  status from an OpenTelemetry Go [Approver] or [Maintainer].
-[^2]: Trivial changes include: typo corrections, cosmetic non-substantive
-  changes, documentation corrections or updates, dependency updates, etc.
+Any Maintainer can merge the PR once it is **ready to merge**.
 
 ## Design Choices
 
@@ -244,7 +216,7 @@ Meaning a `config` from one package should not be directly used by another. The
 one exception is the API packages.  The configs from the base API, eg.
 `go.opentelemetry.io/otel/trace.TracerConfig` and
 `go.opentelemetry.io/otel/metric.InstrumentConfig`, are intended to be consumed
-by the SDK therefore it is expected that these are exported.
+by the SDK therefor it is expected that these are exported.
 
 When a config is exported we want to maintain forward and backward
 compatibility, to achieve this no fields should be exported but should
@@ -262,12 +234,12 @@ func newConfig(options ...Option) config {
 	for _, option := range options {
 		config = option.apply(config)
 	}
-	// Perform any validation here.
+	// Preform any validation here.
 	return config
 }
 ```
 
-If validation of the `config` options is also performed this can return an
+If validation of the `config` options is also preformed this can return an
 error as well that is expected to be handled by the instantiation function
 or propagated to the user.
 
@@ -466,7 +438,7 @@ their parameters appropriately named.
 #### Interface Stability
 
 All exported stable interfaces that include the following warning in their
-documentation are allowed to be extended with additional methods.
+doumentation are allowed to be extended with additional methods.
 
 > Warning: methods may be added to this interface in minor releases.
 
@@ -528,30 +500,27 @@ interface that defines the specific functionality should be preferred.
 
 ## Approvers and Maintainers
 
-### Approvers
+Approvers:
 
 - [Evan Torrie](https://github.com/evantorrie), Verizon Media
+- [Josh MacDonald](https://github.com/jmacd), LightStep
 - [Sam Xie](https://github.com/XSAM), Cisco/AppDynamics
 - [David Ashpole](https://github.com/dashpole), Google
 - [Robert Pająk](https://github.com/pellared), Splunk
 - [Chester Cheung](https://github.com/hanyuancheung), Tencent
 - [Damien Mathieu](https://github.com/dmathieu), Elastic
 
-### Maintainers
+Maintainers:
 
 - [Aaron Clawson](https://github.com/MadVikingGod), LightStep
 - [Anthony Mirabella](https://github.com/Aneurysm9), AWS
 - [Tyler Yahn](https://github.com/MrAlias), Splunk
 
-### Emeritus
+Emeritus:
 
 - [Gustavo Silva Paiva](https://github.com/paivagustavo), LightStep
-- [Josh MacDonald](https://github.com/jmacd), LightStep
 
 ### Become an Approver or a Maintainer
 
 See the [community membership document in OpenTelemetry community
 repo](https://github.com/open-telemetry/community/blob/main/community-membership.md).
-
-[Approver]: #approvers
-[Maintainer]: #maintainers