From f4ebf31dd57c19c3546796ba34dff9ab3ba56a15 Mon Sep 17 00:00:00 2001
From: Stefan Prodan <stefan.prodan@gmail.com>
Date: Tue, 30 Nov 2021 16:28:29 +0200
Subject: [PATCH] Add template to RFC-0000

Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
---
 rfcs/README.md          | 96 +----------------------------------------
 rfcs/RFC-0000/README.md | 92 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+), 95 deletions(-)
 create mode 100644 rfcs/RFC-0000/README.md

diff --git a/rfcs/README.md b/rfcs/README.md
index e13b2984e9..07a049fdac 100644
--- a/rfcs/README.md
+++ b/rfcs/README.md
@@ -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.
--->
-```
diff --git a/rfcs/RFC-0000/README.md b/rfcs/RFC-0000/README.md
new file mode 100644
index 0000000000..c32530063d
--- /dev/null
+++ b/rfcs/RFC-0000/README.md
@@ -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.
+-->