Toggle diff (254 lines)
diff --git a/rfc/0000-template.txt b/rfc/0000-template.txt
new file mode 100644
index 0000000000..22dca35a56
--- /dev/null
+++ b/rfc/0000-template.txt
@@ -0,0 +1,58 @@
+# -*- 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 use case as clearly as possible and optionally give an example.
+Explain how the status quo is insufficient or not ideal. This section answers
+Why is this proposal a good idea? Why is it worth the effort to discuss and
+implement such?
+
+* Detail design
+
+Main part. The sections answers What is the cost 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
+
+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.
+
+* 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.
diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
new file mode 100644
index 0000000000..8424303949
--- /dev/null
+++ b/rfc/0001-rfc-process.txt
@@ -0,0 +1,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
base-commit: c0895371c5759c7d9edb330774e90f192cc4cf2c
--
2.41.0
