Add template

This commit is contained in:
Mihai Fufezan 2024-06-06 18:34:00 +03:00
parent 55385d2bb3
commit 3965580f56
3 changed files with 83 additions and 3 deletions

79
0000-template.md Normal file
View File

@ -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?

View File

@ -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">

1
rfcs/.keep Normal file
View File

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