1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
| | # -*- mode:org -*-
#+TITLE: <The meaningful name of the proposal>
#+DATE: <date when the process starts>
+ Issue: <number assigned by Debbugs>
+ Status: <pending|done|unsuccessful|deprecated>
+ Supporter: <Your Name>
+ Co-supporter(s): <Some> <Names>
* Summary
A one-paragraph explanation. Main sales pitch.
* Motivation
Describe the problem·s this RFC attempts to address as clearly as possible and
optionally give an example. Explain how the status quo is insufficient or not
ideal.
* Detail design
Main part. The sections answers What are the tradeoffs of this proposal
compared to status quo or potential alternatives? Explain details, corner
cases, provide examples. Explain it so that someone familiar can understand.
It is best to exemplify, contrived example too. If the Motivation section
describes something that is hard to do without this proposal, this is a good
place to show how easy that thing is to do with the proposal.
** Backward compatibility
# Christopher Baines:
# I'm struggling to think of exactly how backwards compatibility would
# apply to potential RFCs for Guix.
Will your proposed change cause a behaviour change? Assess the expected
impact on existing code on the following scale:
0. No breakage
1. Breakage only in extremely rare cases (exotic or unknown cases)
2. Breakage in rare cases (user living in cutting-edge)
3. Breakage in common cases
Explain why the benefits of the change outweigh the costs of breakage.
Describe the migration path. Consider specifying a compatibility warning for
one or more releases. Give examples of error that will be reported for
previously-working cases; do they make it easy for users to understand what
needs to change and why?
The aim is to explicitely consider beforehand potential Backward Compatibility
issue.
** Forward compatibility
# Christopher Baines:
# I do think it's worth explicitly bringing up something like the "cost of
# reverting". That is, it's important to discuss things more if there's a
# high cost to changing the approach later. For these "high cost of later
# change" situations, the RFC process will probably be particularly
# valuable.
# Noé Lopez:
# I think this section could apply very well to governance proposals.
How will your proposed change evolve with time? What is the cost of changing
the approach later?
* Unresolved questions
Explicitly list any remaining issues. At submitting time, be upfront and
trust that the community will help. At reviewing time, this section tracks
the details about the status of the process.
At the end of the process, this section will be empty. If not, please be
explicit with the known issues by adding a dedicated subsection under Detail
design.
|