Skip to content

Commit a78c94c

Browse files
NathanielRNocelotl
andauthored
README includes 1.0 release checklist + CODEOWNER description (open-telemetry#596)
* README 1.0 release checklist + what is a CODEOWNER * Do not required SLA for responding to asks * Easy changes to address reviewer comments * Introduce on Slack at least not SIG meeting * Give guidance when a CODEOWNER wants to leave a project * Update README.md Take suggestion package "MUST" wording. Co-authored-by: Diego Hurtado <[email protected]> * Update README.md Take suggestion on CODEOWNER requirement wording. Co-authored-by: Diego Hurtado <[email protected]> * Apply suggestions from code review Take more suggestions on checklist list requirements. Co-authored-by: Diego Hurtado <[email protected]> * Update README.md Take suggestion on MUST requirement for documentation. * Add back missing bullet point * Do not say perpetually 1.0 instead say up to maintainers * Make it explicity CODEOWNER is for 1 file * Make OTel Community membership a requirement because the action we use requires it Co-authored-by: Diego Hurtado <[email protected]>
1 parent fd5fc9a commit a78c94c

File tree

3 files changed

+39
-13
lines changed

3 files changed

+39
-13
lines changed

.github/CODEOWNERS

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,26 @@
11
# Code owners file.
22
# This file controls who is tagged for review for any given pull request.
3+
#
4+
# What is a "CODEOWNER"?
5+
#
6+
# A CODEOWNER lends their expertise to a specific package hosted by an OpenTelemetry repository.
7+
#
8+
# A CODEOWNER MUST:
9+
# - introduce themselves on the CNCF OTel Python channel: https://cloud-native.slack.com/archives/C01PD4HUVBL
10+
# - have enough knowledge of the corresponding instrumented library
11+
# - respond to issues
12+
# - fix failing unit tests or any other blockers to the CI/CD workflow
13+
# - update usage of `opentelemetry-python-core` APIs upon the introduction of breaking changes
14+
# - be a member of the OpenTelemetry community so that the `component-owners.yml` action to automatically assign CODEOWNERS to PRs works correctly.
15+
#
16+
317

418
# For anything not explicitly taken by someone else:
519
* @open-telemetry/opentelemetry-python-contrib-approvers
20+
21+
# Learn about CODEOWNERS file format:
22+
# https://help.github.com/en/articles/about-code-owners
23+
#
24+
# Learn about membership in OpenTelemetry community:
25+
# https://github.com/open-telemetry/community/blob/main/community-membership.md
26+
#

CODEOWNERS

Lines changed: 0 additions & 13 deletions
This file was deleted.

README.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -66,6 +66,24 @@ install](https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs)
6666
pip install -e ./instrumentation/opentelemetry-instrumentation-{integration}
6767
```
6868

69+
## Releasing
70+
71+
Maintainers aim to periodically release new versions of the packages in `opentelemetry-python-contrib`.
72+
73+
Contributions that enhance OTel for Python are welcome to be hosted upstream for the benefit of group collaboration. Maintainers will look for things like good documentation, good unit tests, and in general their own confidence when deciding to release a package with the stability guarantees that are implied with a `1.0` release.
74+
75+
To resolve this, members of the community are encouraged to commit to becoming a CODEOWNER for packages in `-contrib` that they feel experienced enough to maintain. CODEOWNERS can then follow the checklist below to release `-contrib` packages as 1.0 stable:
76+
77+
### Releasing a package as `1.0` stable
78+
79+
To release a package as `1.0` stable, the package:
80+
- SHOULD have a CODEOWNER. To become one, submit an issue and explain why you meet the responsibilities found in [CODEOWNERS](.github/CODEOWNERS).
81+
- MUST have unit tests that cover all supported versions of the instrumented library.
82+
- e.g. Instrumentation packages might use different techniques to instrument different major versions of python packages
83+
- MUST have clear documentation for non-obvious usages of the package
84+
- e.g. If an instrumentation package uses flags, a token as context, or parameters that are not typical of the `BaseInstrumentor` class, these are documented
85+
- After the release of `1.0`, a CODEOWNER may no longer feel like they have the bandwidth to meet the responsibilities of maintaining the package. That's not a problem at all, life happens! However, if that is the case, we ask that the CODEOWNER please raise an issue indicating that they would like to be removed as a CODEOWNER so that they don't get pinged on future PRs. Ultimately, we hope to use that issue to find a new CODEOWNER.
86+
6987
## Contributing
7088

7189
See [CONTRIBUTING.md](CONTRIBUTING.md)

0 commit comments

Comments
 (0)