Verified Commit 771cc4c2 authored by David Runge's avatar David Runge
Browse files

Add RFC about using the RFC process

Add a first, fairly simple (most of the relevant **Specification**
information is found in the README of the repository) RFC about using
the RFC system to steer Arch Linux.
Add a section about existing (fairly recent) documentation in the wiki.
Add a few sentences to outline the different entities Arch Linux
consists of and what the RFC process is improving upon.
Clarify the setup of the final comment period, after which the RFC is
either accepted or rejected.
Expand upon how and why the specialized communication channels are
insufficient for solving overarching topics.
Specify that the discussion takes place in the merge request itself.
Add information on how RFC ideas may be proposed and existing ones
Expand specification section by a paragraph on who is allowed to create
an RFC (anyone) and explain what are the limitations for outside
contributors (they can only create an RFC if at least one Developer or
Trusted User supports the topic and helps to develop it).
Elaborate on how in the current situation the decision making process or
found consensus may be oblique to newcomers (or even long term staff)
and that RFCs serve as an ongoing standardized archive of discussions
and found consensus.
Mention GitLab's approval feature as a means to approve of an RFC
alongside the possibility to leave a comment for a more nuanced motion.
parent 9201828a
Using RFCs
- Date proposed: 2021-02-03
A Request for Comment (RFC) is a way for Arch Linux contributors to propose,
design, and discuss new features and changes in project direction in a focused
Finding consensus on overarching or more involved topics in Arch Linux has
historically been driven by discussions on mailing lists, in the distribution's
various IRC channels, the wiki and the forums.
While under certain circumstances this process is still valid and does work, it
has a tendency to lead to unfocused and inconclusive discussions while lacking
a transparent process.
In addition, the results of decision-making are often oblique to newcomers, as
they may only exist in the logs of chats or mailing lists, that are not
accessible to everyone.
When considering the different entities (project leader, developers, trusted
users, support staff) that Arch Linux consists of, it becomes apparent that
distribution-wide topics do not have a platform, as the specific entities have
specialized (access-restricted) communication channels and concern themselves
(sometimes exclusively) with a specialized topic.
With the wiki article `Governance And Decision Making
an attempt has been made to outline the existing decision making processes and
put them into context with one another.
The RFC process is meant to guide and transform the distribution as a whole,
in contrast to the various specialized entities (project leader, developers,
trusted users, support staff) and their respective communication channels.
To increase transparency, source and value the knowledge and inspiration of the
entire community, an RFC based process can be used to achieve a more focused
workflow for discussing overarching topics and reaching a conclusion for the
entire distribution, while archiving discussion and consensus in a standardized
The repository is used to explain
how to create, discuss, finalize and to host the accepted and rejected RFCs.
An RFC is filed by creating a merge request toward the repository.
Anyone is able to create an RFC. However, contributors outside of the Arch
Linux Developer or Trusted User teams are only allowed to create an RFC, if at
least one Developer or Trusted User supports the effort and helps develop it.
New RFC proposals are announced on the `arch-dev-public
<>`_ mailing list and are
open for discussion and contribution in the merge request until finalized.
Once finalized, the RFC is entering its final comment period, which is again
announced on the `arch-dev-public
<>`_ mailing list and lasts
for 14 days. The final comment period is used to gather the motion of all
participants (again as part of the merge request) to either lead to a passed
(by merging the merge request) or rejected (by rejecting the merge request)
RFC. Participants can either use GitLab's approval feature to approve of the
RFC, or leave a comment for a more nuanced motion.
The described process allows developers, trusted users, support staff and users
alike to write an RFC and propose a change in direction for the distribution.
Ideas for RFCs may be proposed and discussed by creating a new `issue
<>`_ using the "idea"
template. Existing ideas for RFCs can be found by browsing the `issues
The RFC workflow breaks with the old way of reaching consensus and might be
perceived as bureaucratic.
Unresolved Questions
Alternatives Considered
- Mailing lists: The existing mailing list infrastructure has been used to
reach consensus on various topics over the years. However, finding the
reached consensus in a comprehensible format is not easy and depending on
topic can be hidden on an access restricted mailing list.
- IRC channels: The existing staff related IRC channels on are
frequently used to reach consensus on minor topics, which then usually find
their way into e-mails or other announcements. However, not all staff is
present on IRC (at all times of the day), so it is easy to miss discussions
or any reached consensus in this medium, if it is not propagated publicly
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment