all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
blob 84243039495b5507fa3e500964027af58e07e46c 7498 bytes (raw)
name: rfc/0001-rfc-process.txt 	 # note: path name is non-authoritative(*)

  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
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
 
# -*- mode:org -*-
#+TITLE: Request-For-Comment process
#+DATE: 2023-10-31

+ Issue: 66844
+ Status: pending
+ Supporter: Simon Tournier
+ Co-supporters:

* Summary

The "RFC" (request for comments) process is intended to provide a consistent
and controlled path for new features to enter the Guix project, so that all
stakeholders can be confident about the direction it is evolving in.

* Motivation

The freewheeling way that we add new features to Guix has been good for early
development, but for Guix to become a broadly used system we need to develop
some more self-discipline when it comes to changing our beloved system.  This
is a proposal for a more principled RFC process to make it a more integral
part of the overall development process, and one that is followed consistently
to introduce substancial features.

There are a number of changes that are significant enough that they could
benefit from wider community consensus before being introduced.  Either
because they introduce new concepts, big changes or are controversial enough
that not everybody will agree on the direction to take.

Therefore, the purpose of this RFC is to introduce a process that allows to
bring the discussion upfront and strengthen decisions.  This RFC is used to
bootstrap the process and further RFCs can be used to refine the process.

Note that this process does not cover most of the changes.  It covers
significant changes, for some examples:

 + change of inputs style
   (Removing input labels from package definitions, #49169)
 + introduction of =guix shell= and deprecation of =guix environment=
   (Add 'guix shell' to subsume 'guix environment', #50960)
 + introduction of authentication mechanism (Trustable "guix pull", #22883)
 + massive Python 2 removal
   (Merging the purge-python2-packages branch, mailing list guix-devel)
 + collaboration via team and branch-features
   (several places mailing list guix-devel)

* Detail design

** When you need to follow this process

This process is followed when one intends to make "substantial" changes to the
Guix project.  What constitutes a "substantial" change is evolving based on
community norms, but may include the following.

  + Any change that modifies Guix API
  + Big restructuring of packages
  + Introduction or removal of subcommands

Certain changes do not require an RFC:

  - Adding, updating packages, removing outdated packages
  - Fixing security updates and bugs that don't break interfaces

A patch submission to Debbugs that contains any of the afore-mentioned
substantial changes may be asked to first submit a RFC.

** How the process works

  1. Clone https://git.savannah.gnu.org/git/guix.git
  2. Copy rfc/0000-template.org to rfc/00XY-good-name.org where good-name is
     descriptive but not too long and XY increments
  3. Fill RFC
  4. Submit to guix-patches@gnu.org

Make sure the proposal is as well-written as you would expect the final
version of it to be.  It does not mean that all the subtilities must be
considered at this point since that is the aim of review discussion.  It means
that the RFC process is not a prospective brainstorming and the proposal
formalize an idea for making it happen.

The submission of a proposal does not require an implementation.  However, to
improve the chance of a successful RFC, it might be recommended to have an
idea for implementing it.  If an implementation is attached to the detailed
design, it might help the discussion.

At this point, at least one other person must volunteer to be "co-supporter".
The aim is to improve the chances that the RFC is both desired and likely to
be implemented.

Once supporter and co-supporter(s) are committed in the RFC process, the
review discussion starts.  Advertisement of the RFC on the mailing-lists
guix-devel is mandatory and IRC is recommended.

After a number of rounds of review, the discussion should settle and a general
consensus should emerge.  If the RFC is successful then authors may contribute
to the implementation.  This bit is left intentionally vague and should be
refined in the future.

A successful RFC is not a rubber stamp, and in particular still does not mean
the feature will ultimately be merged; it does mean that in principle all the
major stakeholders have agreed to the feature and are amenable to merging it.

An unsuccessful RFC is *not* a judgment on the value of the work, so a refusal
should rather be interpreted as “let’s discuss again with a different angle”.
The last state of an unsuccessful RFC is archived under the directory
rfcs/unsuccessful/.

** Co-supporter

A co-supporter is a contributor sufficiently familiar with the project’s
practices, hence it is recommended, but not mandatory, to be a contributor
with commit access.  The co-supporter helps the supporter, they are both
charged with keeping the proposal moving through the process.  The
co-supporter role is to help the proposal supporter by being the timekeeper
and helps in pushing forward until process completion.

The co-supporter doesn't necessarily have to agree with all the points of the
RFC but should generally be satisfied that the proposed additions are a good
thing for the community.

** Comment period

It is up to the supporter and co-supporter to ensure that sufficient
discussion is solicited.  Let two weeks for people to comment is a good
average.  Make sure that all have the time for expressing their comments.  The
proposal is about significant changes, thus more time is better than less.

** Decision making: consensus

It is expected from all contributors, and even more so from committers, to
help build consensus and make decisions based on consensus.  By using
consensus, we are committed to finding solutions that everyone can live with.

It implies that no decision is made against significant concerns and these
concerns are actively resolved with proposals that work for everyone.  A
contributor, without or with commit access, wishing to block a proposal bears
a special responsibility for finding alternatives, proposing ideas/code or
explaining the rationale for the status quo.

To learn what consensus decision making means and understand its finer
details, you are encouraged to read
<https://www.seedsforchange.org.uk/consensus>.

** Merging the outcome

Whoever merges the successful RFC should do the following:

 1. Fill in the remaining metadata in the RFC header, including links for the
    original Debbugs submission.
 2. Commit everything.

** Template of RFC

The structure of the RFC is captured by the template; see the file
rfc/0000-template.txt.  It is recommended to write using markup language as,
for example, Org-mode or Markdown or reStructuredText.

** Backward Compatibility

None.

** Drawbacks

There is a risk that the additional process will hinder contribution more than
it would help.  We should stay alert that the process is only a way to help
contribution, not an end in itself.

Of course, group decision-making processes are difficult to manage.

The ease of commenting may bring a slightly diminished signal-to-noise ratio
in collected feedback, particularly on easily bike-shedded topics.

** Open questions

There are still questions regarding the desired scope of the process.  While
we want to ensure that changes which affect the users are well-considered, we
certainly don't want the process to become unduly burdensome.  This is a
careful balance which will require care to maintain moving forward.

* Unresolved questions

debug log:

solving 8424303949 ...
found 8424303949 in https://yhetil.org/guix/dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@gmail.com/

applying [1/1] https://yhetil.org/guix/dbae3bd79e489fe219e6b9d54b194b0248c1310a.1698750444.git.zimon.toutoune@gmail.com/
diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
new file mode 100644
index 0000000000..8424303949

Checking patch rfc/0001-rfc-process.txt...
Applied patch rfc/0001-rfc-process.txt cleanly.

index at:
100644 84243039495b5507fa3e500964027af58e07e46c	rfc/0001-rfc-process.txt

(*) Git path names are given by the tree(s) the blob belongs to.
    Blobs themselves have no identifier aside from the hash of its contents.^

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.