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

CONTRIBUTING.md

@@ -193,3 +193,6 @@ on each other), the owner should try to get people aligned by:
 If none of the above worked and the PR has been stuck for more than 2 weeks, the
 owner should bring it to the [OpenTelemetry Specification SIG
 meeting](https://github.com/open-telemetry/community#cross-language-specification).
+
+New signal release reviews are subject to different rules that and do not follow
+the above process. For that please see [here](releases/new-signal-release-process.md).

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

@@ -0,0 +1,55 @@
+# 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 are expected to work with the
+language maintainers and/or invited language experts to perform this review
+process. Language maintainers SHOULD respond to any question/issue
+(github issues, github discussions, gitter, or comments in the review PR)
+during the review time in a reasonable amount of time to not delay the review
+process (ideally 1 business day).
+
+It is highly recommended to have at least 2 members of the Technical Committee
+as sponsors. Any Technical Committee member 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 public API 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,46 @@
+# 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 OpenTelemetry 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 (2 weeks)
+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`,
+and the title of the PR MUST be `Release review for ${LANGUAGE}/${SIGNAL}/v${MAJOR_VERSION}`.
+
+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 (a good time would be immediately after the
+release of the first RC), 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 public API because that will cause the review to invalidate and the
+process needs to be redone.