Mirrors
/
flux2
mirror of https://github.com/fluxcd/flux2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add template to RFC-0000

Browse Source 
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
pull/2085/head
Stefan Prodan 3 years ago
parent 99a0c47277
commit 2c3cb1a664
No known key found for this signature in database
GPG Key ID: 3299AEB0E4085BAF
2 changed files with 93 additions and 95 deletions
Show Stats Download Patch File Download Diff File

96
rfcs/README.md
Unescape Escape View File

@ -24,7 +24,7 @@ Examples of substantial changes:
- Before submitting an RFC please discuss the proposal with the Flux community.
Start a discussion on GitHub and ask for feedback at the weekly dev meeting.
You must find a maintainer willing to sponsor the RFC.
- Submit an RFC by opening a pull request using RFC-0000 as template.
- Submit an RFC by opening a pull request using [RFC-0000](RFC-0000/README.md) as template.
- The sponsor will assign the PR to themselves, will label the PR with `area/RFC` and
will request other maintainers to begin the review process.
- Integrate feedback by adding commits without overriding the history.
@ -43,97 +43,3 @@ Examples of substantial changes:
resides with the maintainers that reviewed the code changes.
- A new RFC could be summited with the scope of replacing an RFC rejected during implementation.
The new RFC must come with a solution for the rejection motives of the previous RFC.
## RFC Template
```text
# RFC-NNNN Title
<!--
The title must be short and descriptive.
-->
**Status:** provisional
<!--
Status represents the current state of the RFC.
Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejected`, `withdrawn`, or `replaced`.
-->
**Creation Date:** YYYY-MM-DD
**Last update:** YYYY-MM-DD
## Summary
<!--
One paragraph explanation of the proposed feature or enhancement.
-->
## Motivation
<!--
This section is for explicitly listing the motivation, goals, and non-goals of
this RFC. Describe why the change is important and the benefits to users.
-->
### Goals
<!--
List the specific goals of this RFC. What is it trying to achieve? How will we
know that this has succeeded?
-->
### Non-Goals
<!--
What is out of scope for this RFC? Listing non-goals helps to focus discussion
and make progress.
-->
## Proposal
<!--
This is where we get down to the specifics of what the proposal actually is.
This should have enough detail that reviewers can understand exactly what
you're proposing, but should not include things like API designs or
implementation.
-->
### User Stories
<!--
Optional if existing discussions and/or issues are linked in the motivation section.
-->
### Alternatives
<!--
List plausible alternatives to the proposal and explain why the proposal is superior.
This is a good place to incorporate suggestions made during discussion of the RFC.
-->
## Design Details
<!--
This section should contain enough information that the specifics of your
change are understandable. This may include API specs and code snippets.
The design details should address at least the following questions:
- How can this feature be enabled / disabled?
- Does enabling the feature change any default behavior?
- Can the feature be disabled once it has been enabled?
- How can an operator determine if the feature is in use?
- Are there any drawbacks when enabling this feature?
-->
## Implementation History
<!--
Major milestones in the lifecycle of the RFC such as:
- The first Flux release where an initial version of the RFC was available.
- The version of Flux where the RFC graduated to general availability.
- The version of Flux where the RFC was retired or superseded.
-->
```

92
rfcs/RFC-0000/README.md
Unescape Escape View File

@ -0,0 +1,92 @@
# RFC-NNNN Title
<!--
The title must be short and descriptive.
-->
**Status:** provisional
<!--
Status represents the current state of the RFC.
Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejected`, `withdrawn`, or `replaced`.
-->
**Creation date:** YYYY-MM-DD
**Last update:** YYYY-MM-DD
## Summary
<!--
One paragraph explanation of the proposed feature or enhancement.
-->
## Motivation
<!--
This section is for explicitly listing the motivation, goals, and non-goals of
this RFC. Describe why the change is important and the benefits to users.
-->
### Goals
<!--
List the specific goals of this RFC. What is it trying to achieve? How will we
know that this has succeeded?
-->
### Non-Goals
<!--
What is out of scope for this RFC? Listing non-goals helps to focus discussion
and make progress.
-->
## Proposal
<!--
This is where we get down to the specifics of what the proposal actually is.
This should have enough detail that reviewers can understand exactly what
you're proposing, but should not include things like API designs or
implementation.
If the RFC goal is to document best practices,
then this section can be replaced with the the actual documentation.
-->
### User Stories
<!--
Optional if existing discussions and/or issues are linked in the motivation section.
-->
### Alternatives
<!--
List plausible alternatives to the proposal and explain why the proposal is superior.
This is a good place to incorporate suggestions made during discussion of the RFC.
-->
## Design Details
<!--
This section should contain enough information that the specifics of your
change are understandable. This may include API specs and code snippets.
The design details should address at least the following questions:
- How can this feature be enabled / disabled?
- Does enabling the feature change any default behavior?
- Can the feature be disabled once it has been enabled?
- How can an operator determine if the feature is in use?
- Are there any drawbacks when enabling this feature?
-->
## Implementation History
<!--
Major milestones in the lifecycle of the RFC such as:
- The first Flux release where an initial version of the RFC was available.
- The version of Flux where the RFC graduated to general availability.
- The version of Flux where the RFC was retired or superseded.
-->
Write Preview
Loading…
Cancel
Save