README 1.0 release checklist + what is a CODEOWNER

Author: NathanielRN

Diff for: .github/CODEOWNERS

@@ -1,5 +1,27 @@
 # Code owners file.
 # This file controls who is tagged for review for any given pull request.
+#
+# What is a "CODEOWNER"?
+#
+# A CODEOWNER MUST ____ for packages they own:
+# - introduce themselves at a Python SIG meeting
+# - demonstrate advanced knowledge of the dependencies
+# - respond to issues when they are notified
+# - fix failing unit tests or any other blockers to the CI/CD workflow
+# - update usage of `opentelemetry-python-core` APIs upon the introduction of breaking changes
+# - respond within 2~3 business days for any of the above asks
+#
+# A CODEOWNER SHOULD:
+# - be a member of the OpenTelemetry community
+#
+
 
 # For anything not explicitly taken by someone else:
 * @open-telemetry/opentelemetry-python-contrib-approvers
+
+# Learn about CODEOWNERS file format:
+# https://help.github.com/en/articles/about-code-owners
+#
+# Learn about membership in OpenTelemetry community:
+# https://github.com/open-telemetry/community/blob/main/community-membership.md
+#

Diff for: CODEOWNERS

@@ -66,6 +66,23 @@ install](https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs)
 pip install -e ./instrumentation/opentelemetry-instrumentation-{integration}
 ```
 
+## Releasing
+
+Maintainers aim to periodically release new versions of the packages in `opentelemetry-python-contrib`.
+
+Contributions that enhance OTel for Python are welcome to be hosted upstream for the benefit of group collaboration. However, as a general rule, releases for packages in `opentelemetry-python-contrib` will be in a perpetual `~=0.X.0` (pre-1.0) version state. This is because maintainers and approvers cannot feasibly provide the stability guarantees that are implied with a 1.0 release for so many packages.
+
+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:
+
+### Releasing a package as `1.0` stable
+
+To release a package as `1.0` stable, the package MUST...:
+- [ ] Have a CODEOWNER. Submit an issue to become a CODEOWNER of a package and explain why you meet the responsibilities found in [CODEOWNERS](.github/CODEOWNERS)
+- [ ] Have unit tests that cover difference between versions the package claims to support
+  - e.g. Instrumentation packages might use different techniques to instrument different major versions of python packages
+- [ ] Have clear documentation for non-obvious usages of the package
+  - 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
+
 ## Contributing
 
 See [CONTRIBUTING.md](CONTRIBUTING.md)