opensource/opentelemetry-python-contrib
1
0
Fork 0
mirror of https://github.com/open-telemetry/opentelemetry-python-contrib.git synced 2025-07-30 05:32:30 +08:00
Code Issues Packages Projects Releases Wiki Activity

documentation on what entries require a changelog

Browse Source 
There were questions regarding what situations require a changelog.

The intent of this change is to make the changelog requirements more
easily discoverable and clear.
This commit is contained in:
Yusuke Tsutsumi
2020-11-10 21:33:13 -08:00
parent 79b519f5cc
commit daf01cc93f
2 changed files with 5 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/pull_request_template.md vendored
View File

@ -21,6 +21,8 @@ Please describe the tests that you ran to verify your changes. Provide instructi
# Checklist:
See [contributing.md](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/master/CONTRIBUTING.md) for styleguide, changelog guidelines, and more.
- [ ] Followed the style guidelines of this project
- [ ] Changelogs have been updated
- [ ] Unit tests have been added

5
CONTRIBUTING.md
View File

@ -104,12 +104,13 @@ A PR is considered to be **ready to merge** when:
reasonable time to review.
* Trivial change (typo, cosmetic, doc, etc.) doesn't have to wait for one day.
* Urgent fix can take exception as long as it has been actively communicated.
* A changelog entry is added to the corresponding changelog for the code base, if there is any impact on behavior. e.g. doc entries are not required, but small bug entries are.
Any Approver / Maintainer can merge the PR once it is **ready to merge**.
## Design Choices
As with other OpenTelemetry clients, opentelemetry-python follows the
As with other OpenTelemetry clients, opentelemetry-python follows the
[opentelemetry-specification](https://github.com/open-telemetry/opentelemetry-specification).
It's especially valuable to read through the [library guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/library-guidelines.md).
@ -122,7 +123,7 @@ use cases are clear, but the method to satisfy those uses cases are not.
As such, contributions should provide functionality and behavior that
conforms to the specification, but the interface and structure is flexible.
It is preferable to have contributions follow the idioms of the language
It is preferable to have contributions follow the idioms of the 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