From a42426d2d54779aec1eb5314faf597ea7c664532 Mon Sep 17 00:00:00 2001
From: Jacob Aronoff <jaronoff97@users.noreply.github.com>
Date: Wed, 21 Aug 2024 10:56:04 -0400
Subject: [PATCH] Create RFC template (#3193)

* Create RFC template

* include process doc

* feedback

* spacing

* enumerate status
---
 docs/rfcs/README.md   | 30 ++++++++++++++++++++++++++++
 docs/rfcs/template.md | 46 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 76 insertions(+)
 create mode 100644 docs/rfcs/README.md
 create mode 100644 docs/rfcs/template.md

diff --git a/docs/rfcs/README.md b/docs/rfcs/README.md
new file mode 100644
index 0000000000..d7cb97e225
--- /dev/null
+++ b/docs/rfcs/README.md
@@ -0,0 +1,30 @@
+# RFC Process
+
+The RFC process for the OpenTelemetry Operator exists so that community members can effectively review and understand
+major decisions made by the Operator SIG. The RFC process also allows users to comment asynchronously on design
+decisions.
+
+We aim to improve the experience for using OpenTelemetry tools in a Kubernetes
+environment. Proposals here should only focus on improving that experience by composing existing
+OpenTelemetry components such as the OpenTelemetry Collector, OpenTelemetry Instrumentation, OpAMP, etc.
+If a proposal requires new components to exist that do not logically fit within that mission, it's recommended to
+open proposals with the proper SIGs.
+
+## Process
+
+1. Copy and fill the [template.md](./template.md) document
+2. Open a PR to get initial feedback on RFC
+3. The RFC must be discussed at the Operator SIG Meeting at least once prior to merge
+4. Upon merge, the RFC's status will still be Draft. At this point, the RFC has been accepted and an implementation
+can be started
+   1. The initial implementation's PR should change the status to accepted
+   2. If any significant changes are made that deviate from the RFC, the RFC should be updated to reflect that
+
+## Recommendations
+
+During the RFC process, the [template.md](./template.md) must be filled out. We recommend also doing the following:
+
+* Include a proof-of-concept to confirm the design
+* Share alternatives considered and tradeoffs
+  * A valid alternative to consider is always "do nothing"
+* Pair with a SIG member to sort through unknowns / ask for help
diff --git a/docs/rfcs/template.md b/docs/rfcs/template.md
new file mode 100644
index 0000000000..8bd1d3712c
--- /dev/null
+++ b/docs/rfcs/template.md
@@ -0,0 +1,46 @@
+# TITLE
+
+**Status:** [*Draft* | *Accepted*]
+
+**Author:** <your-name>
+
+**Date:** <todays-date>
+
+
+## Objective
+
+[comment]: # (Describe the objective for this proposal)
+
+## Summary
+
+[comment]: # (Summarize the design for the proposal)
+
+## Goals and non-goals
+
+[comment]: # (Describe the objective for this proposal)
+
+## Use cases for proposal
+
+### CASE 1
+
+[comment]: # (Describe case #1)
+
+### CASE 2
+
+[comment]: # (Describe case #2)
+
+### CASE N
+
+[comment]: # (Describe case #N)
+
+## Struct Design
+
+[comment]: # (Describe the go struct that will be introduced for this change, if applicable)
+
+## Rollout Plan
+
+[comment]: # (Describe how the change will be rolled out in the operator repo and for users)
+
+## Limitations
+
+[comment]: # (Describe the limitations and design decisions made here)