-
Notifications
You must be signed in to change notification settings - Fork 420
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Create RFC template * include process doc * feedback * spacing * enumerate status
- Loading branch information
1 parent
3b1eac2
commit a42426d
Showing
2 changed files
with
76 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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) |