From 9cb0761ffee699e51b36fe857a1b35d0de24a68f Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Fri, 18 Oct 2024 00:06:15 +0200 Subject: [PATCH] [docs/rfc] Define RFC merge process (#11416) #### Description Define RFC merge process in the `docs/rfc/README.md`. This is meant to be a tool for making decisions about hard stuff :) --------- Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com> Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com> --- docs/rfcs/README.md | 73 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 69 insertions(+), 4 deletions(-) diff --git a/docs/rfcs/README.md b/docs/rfcs/README.md index 7d15f803bc4..395b635fe0d 100644 --- a/docs/rfcs/README.md +++ b/docs/rfcs/README.md @@ -1,10 +1,75 @@ # Collector RFCs -This folder contains accepted design documents for the Collector. -Proposals here imply changes only on the OpenTelemetry Collector and not on other parts of OpenTelemetry; if you have a cross-cutting proposal, file an [OTEP][1] instead. +This folder contains accepted design documents for the Collector. Proposals here imply changes only +on the OpenTelemetry Collector and not on other parts of OpenTelemetry; if you have a cross-cutting +proposal, file an [OTEP][1] instead. -Accepted RFCs: +# RFC Process -- [OpenTelemetry Collector Processor Exploration](./processing.md) +## Scope + +The Request For Comments (RFC) process is intended to be used for significant changes to the Collector. Major design +decisions, especially those that imply a change that is hard to reverse, should generally be +documented as an RFC. Controversial changes should also be documented as an RFC, so that the +community can have a chance to provide feedback. The goal of this process is to ensure we have a +coherent vision before embarking on significant work. + +Ultimately, if any opentelemetry-collector maintainer feels that a change requires an RFC, then a +merged RFC is a requirement for said change. + +## Contents + +We are purposefully light on the structure of RFCs, with the focus being the decision process and +not the document itself. When in doubt, the [OTEP template][2] can be a good starting point. +Regardless of the structure, the RFC should make clear what commitments are being made by the +Collector SIG when merging it. + +## Announcement + +RFCs should be announced in a Collector SIG meeting and on the #otel-collector-dev Slack channel. + +## Approval process + +An RFC is just like any other PR in this repository, with the exception of more stringent criteria +for merging it. + +### Stakeholders + +To define merge criteria and voting, each RFC has a set of 'stakeholders'. All +opentelemetry-collector approvers are considered stakeholders. Additional stakeholders (e.g. +maintainers of related SIGs or experts) may be explicitly noted in the RFC. + +### Merge rules + +We use a [Lazy Consensus](https://www.apache.org/foundation/glossary.html#LazyConsensus) method with the following rules: + +1. *Quorum*: For an RFC to be mergeable, it needs to have at least **two approvals** from the + approvers set as well as approvals from any additional stakeholders. +2. *Waiting period*: Maintainers need to announce their intent to merge the RFC with a GitHub + comment. They will need to add a `rfc:final-comment-period` label to the PR and wait for at least + **4 business days** after making the announcement to merge the RFC. +3. *Objections*: Objections should be communicated as a 'request changes' review. All objections + must be addressed before merging an RFC. If addressing an objection does not appear feasible, any + maintainer may call for a vote to be made on the objection (see below). This will be signified by + adding a `rfc:vote-needed` label to the PR. The voting result is binding and a maintainer can + drop any 'request changes' reviews based on the vote results or consensus. +4. *Modifications*: Non-trivial modifications to an RFC reset the waiting period. RFC authors must + re-request any approving, comment, or 'request changes' reviews if the RFC has been modified significantly. + +### Voting + +If there is no consensus on a particular issue, a vote may be called by any of the maintainers. The +vote will be open to all stakeholders for at least **5 business days** or until at least one third +of the stakeholders have voted, whichever comes last. The vote will be decided by simple majority, +restricting the set to approvers and then maintainers in case of a tie among stakeholders. + +Voting should be done on a dedicated issue via comments. The related discussion threads should be +linked in the issue. The voting result should be documented in the RFC itself. + +# Modifications to existing RFCs and to this document + +Non-trivial modifications to this document and to existing RFCs should be done through the RFC +process itself and have the same merge criteria. [1]: https://github.com/open-telemetry/oteps +[2]: https://github.com/open-telemetry/oteps/blob/main/0000-template.md