[Proposal] A pre-release review process for new major releases of any client library

The main idea is that before every major release or the release of a new telemetry type (metrics)
we would like to do a technical and specification conformance review that will ensure consistency
and same "look and feel" for all officially released libraries.

Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>

Author: bogdandrutu

releases/new-signal-release-process-template.md

@@ -0,0 +1,53 @@
+# Technical Review and Specification Conformance for ${Language}/${SIGNAL}/${MAJOR_VERSION} library
+
+Technical Committee Sponsor(s): []
+
+Expected Release Date: []
+
+Expected Version Number: []
+
+Spec Compliance Matrix is up to date: [Permanent link to the matrix]
+
+Versioning And Stability Document: [Link to version document]
+
+Public Code Documentation: [Link to godoc, javadoc, etc.]
+
+Public Examples: [Link to couple of official usage examples]
+
+Discovered Issues: [List of filed issues by the TC members during the review process]
+
+## TODOs
+
+This section must be deleted when the PR for starting the review is opened,
+but it contains a list of important TODOs that maintainers MUST do before starting the process.
+
+The Language Maintainers MUST:
+
+* Prior to starting the review, update the
+[compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md)
+for that language/signal.
+* Each language implementation MUST follow
+[the versioning and stability requirements](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md)
+and prepare the public documentation about the versioning and stability guarantees.
+* Work with a Technical Committee Sponsor(s) during review. The Technical
+Committee members are not language experts, and it is expected to work with the
+language maintainers and/or invited language experts to perform this review
+process. Language maintainers SHOULD respond to any question during the review
+time in a reasonable amount of time to not delay the review process.
+
+It is highly recommended to have at least 2 members of the Technical Committee
+as sponsors. Any Technical Committee can be a sponsor, and any Technical
+Committee member can provide feedback during the review process.
+
+Technical Committee Sponsor(s) MUST:
+
+* Do the due diligence and review the public documentation and examples, and
+ensure specification conformance.
+* Ensure conformance with the versioning and stability document.
+* Ensure consistent names across implementations (e.g. TraceId vs GlobalId)
+* Avoid confusions across implementation (e.g same function returns has different behaviors)
+* Ensure no experimental features (signals) are part of the released packages (e.g. api, sdk, etc.).
+
+The OpenTelemetry Technical Committee MUST attend one of the language SIG
+meetings and have a public discussion with the language maintainers to discuss
+any issues found during the review process.

releases/new-signal-release-process.md

@@ -0,0 +1,44 @@
+# New Signal Release Process
+
+This document defines the release requirements and process followed by the
+OpenTelemetry libraries, along with the rules and procedures for meeting those
+requirements.
+
+In this document, the terms "OpenTelemetry" and "language implementations" both
+specifically refer to the OpenTelemetry client libraries. These terms do not
+refer to the specification or the Collector in this document.
+
+Every OpenTelmetry official major release MUST follow the release process
+proposed in this document. A  "major release" refers to a new version of any
+[signal](../specification/glossary.md#signals) (adding a new signal to an
+already released major version of the library, or a major version bump for an
+existing released signal) for OpenTelemetry client libraries.
+
+The OpenTelemetry [Technical Committee](https://github.com/open-telemetry/community/blob/main/tech-committee-charter.md) (with guidance from language maintainers) is responsible to setup release dates
+and ensure quality standards of the official releases
+[here](https://github.com/open-telemetry/community/blob/main/tech-committee-charter.md#responsibilities-of-the-technical-committee).
+
+To graduate the release process, each language implementation MUST do:
+
+* Technical and Specification Compliance Review
+
+The OpenTelemetry Technical Committee reserves the right to change and improve
+this process during time based on the prior experiences.
+
+## Technical and Specification Compliance Review
+
+The OpenTelemetry [Technical Committee](https://github.com/open-telemetry/community/blob/main/tech-committee-charter.md)
+commits to ensure that every decision will be made in less than 14 days after
+the process is started.
+
+To begin the technical and specification compliance review language maintainers
+MUST submit a PR and complete this [template](new-signal-release-process-template.md).
+The name of the file MUST be `release-review-${language}-${signal}-v${major_version}.md`.
+
+During the review process, breaking changes related to the new signal MAY be
+needed to comply with the specification, it is highly recommended to start
+the process as soon as possible, but after all features and planned changes are merged.
+
+After the review is approved, it is highly recommended to not make any major
+change to the code because that will cause the review to invalidate and the
+process needs to be redone.