diff options
Diffstat (limited to 'vendor/go.opentelemetry.io/otel/CONTRIBUTING.md')
| -rw-r--r-- | vendor/go.opentelemetry.io/otel/CONTRIBUTING.md | 97 |
1 files changed, 33 insertions, 64 deletions
diff --git a/vendor/go.opentelemetry.io/otel/CONTRIBUTING.md b/vendor/go.opentelemetry.io/otel/CONTRIBUTING.md index f521d6543..a6928bfdf 100644 --- a/vendor/go.opentelemetry.io/otel/CONTRIBUTING.md +++ b/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: - -* It has received two qualified approvals[^1]. - - 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. +A PR is considered to be **ready to merge** when: + +* 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. + +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 |