Add template

0000-template.md

@@ -0,0 +1,79 @@
+---
+feature: (fill me in with a unique ident, my_awesome_feature)
+start-date: (fill me in with today's date, YYYY-MM-DD)
+author: (name of the main author)
+co-authors: (find a buddy later to help out with the RFC)
+shepherd-team: (names, to be nominated and accepted by RFC steering committee)
+shepherd-leader: (name to be appointed by RFC steering committee)
+related-issues: (will contain links to implementation PRs)
+---
+
+# Summary
+
+[summary]: #summary
+
+One paragraph explanation of the feature.
+
+# Motivation
+
+[motivation]: #motivation
+
+Why are we doing this? What use cases does it support? What is the expected
+outcome?
+
+# Detailed design
+
+[design]: #detailed-design
+
+This is the core, normative part of the RFC. Explain the design in enough detail
+for somebody familiar with the ecosystem to understand, and implement. This
+should get into specifics and corner-cases. Yet, this section should also be
+terse, avoiding redundancy even at the cost of clarity.
+
+# Examples and Interactions
+
+[examples-and-interactions]: #examples-and-interactions
+
+This section illustrates the detailed design. This section should clarify all
+confusion the reader has from the previous sections. It is especially important
+to counterbalance the desired terseness of the detailed design; if you feel your
+detailed design is rudely short, consider making this section longer instead.
+
+# Drawbacks
+
+[drawbacks]: #drawbacks
+
+What are the disadvantages of doing this?
+
+# Alternatives
+
+[alternatives]: #alternatives
+
+What other designs have been considered? What is the impact of not doing this?
+For each design decision made, discuss possible alternatives and compare them to
+the chosen solution. The reader should be convinced that this is indeed the best
+possible solution for the problem at hand.
+
+# Prior art
+
+[prior-art]: #prior-art
+
+You are unlikely to be the first one to tackle this problem. Try to dig up
+earlier discussions around the topic or prior attempts at improving things.
+Summarize, discuss what was good or bad, and compare to the current proposal. If
+applicable, have a look at what other projects and communities are doing. You
+may also discuss related work here, although some of that might be better
+located in other sections.
+
+# Unresolved questions
+
+[unresolved]: #unresolved-questions
+
+What parts of the design are still TBD or unknowns?
+
+# Future work
+
+[future]: #future-work
+
+What future work, if any, would be implied or impacted by this feature without
+being directly part of the work?

README.md

@@ -126,9 +126,9 @@ _In short, to get a major change propagated to the HyprWM organization or to a
 project under the HyprWM organization, one must first get an RFC merged into the
 RFC repository as a markdown file under the `rfcs` directory, with the file name
 `XXXX-<name>.md` where the `XXXX` in the name stands for the RFC number,
-starting from `0000` At that point the RFC is accepted, and may be implemented
-with the goal of eventual inclusion into HyprWM or a project under the HyprWM
-organization._
+starting from `0000`. A template is available in the root of this repository. At
+that point the RFC is accepted, and may be implemented with the goal of eventual
+inclusion into HyprWM or a project under the HyprWM organization._
 
 <div align="center">
     <img src="./assets/rfc-process.png" alt="RFC Process">

rfcs/.keep

@@ -0,0 +1 @@
+Remove this file when the first RFC is added.