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 instead.
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.
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 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.
RFCs should be announced in a Collector SIG meeting and on the #otel-collector-dev Slack channel.
An RFC is just like any other PR in this repository, with the exception of more stringent criteria for merging it.
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.
We use a Lazy Consensus method with the following rules:
- 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.
- 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-periodlabel to the PR, comment on the PR and note the final comment period in the #otel-collector-dev CNCF Slack channel, and wait for at least 4 business days after making the announcement to merge the RFC. - 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-neededlabel to the PR. The voting result is binding and a maintainer can drop any 'request changes' reviews based on the vote results or consensus. - 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.
- All conversations are resolved: All Github conversations on the PR must be marked as resolved before merging. The RFC author may resolve conversations at their discretion, but they must explain in the conversation thread why they believe it is appropriate to do so.
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.
Non-trivial modifications to this document and to existing RFCs should be done through the RFC process itself and have the same merge criteria.