Toggle diff (340 lines)
diff --git a/rfc/0000-template.txt b/rfc/0000-template.txt
new file mode 100644
index 0000000000..8c4077e753
--- /dev/null
+++ b/rfc/0000-template.txt
@@ -0,0 +1,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.
diff --git a/rfc/0001-rfc-process.txt b/rfc/0001-rfc-process.txt
new file mode 100644
index 0000000000..52d851f879
--- /dev/null
+++ b/rfc/0001-rfc-process.txt
@@ -0,0 +1,248 @@
+# -*- mode:org -*-
+#+TITLE: Request-For-Comment process
+#+DATE: 2023-10-31
+
++ Issue: 66844
++ Status: pending
++ Supporter: Simon Tournier
++ Co-supporters: Noé Lopez
+
+* Summary
+
+The "RFC" (request for comments) process is intended to provide a consistent
+and structured path for major changes and features to enter the Guix project,
+so that all stakeholders can make decisions collectively and be confident
+about the direction it is evolving in.
+
+* Motivation
+
+The current way that we add new features to Guix has been good for early
+development, but it is starting to show its limits as Guix becomes a broadly
+used system with many contributors. Changes might be slowed down by the lack
+of structure to acquire consensus, lack of a central place to consult
+contributors and users, and lack of clear deadlines. 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
+substantial 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 consent 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.
+
+It covers significant changes, where “significant” means any change that could
+only be reverted at a high cost, or any change with the potential to disrupt
+user scripts and programs or user workflows. Examples include:
+
+ - changing the <package> record type and/or its interfaces;
+ - adding or removing a ‘guix’ sub-command;
+ - changing the channel mechanism;
+ - changing project policy such as teams, decision-making, the
+ deprecation policy or this very document;
+ - changing the contributor workflow and related infrastructure
+ (mailing lists, source code repository and forge, continuous
+ integration, etc.)
+
+For concrete past examples where this RFC process would be helpful:
+
+ - Removing input labels from package definitions, #49169
+ - Add 'guix shell' to subsume 'guix environment', #50960
+ + Trustable "guix pull", #22883
+ + Add "Deprecation Policy", #72840
+ + Collaboration via team and branch-features, several places over all the
+ mailing lists.
+
+* Detailed Design
+
+** When To Follow This Trocess
+
+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.
+
+ + Changes that modify user-facing interfaces that may be relied on
+ + Command-line interfaces
+ + Core Scheme interfaces
+ + Big restructuring of packages
+ + Hard to revert changes
+ + Governance and changes to the way we collaborate
+
+Certain changes do not require an RFC:
+
+ - Adding, updating packages, removing outdated packages
+ - Fixing security updates and bugs that don't break interfaces
+
+For general day-to-day contributions, please follow the regular process as
+described by manual sections "Submitting Patches", "Reviewing the Work of
+Others", "Teams" and "Making Decisions".
+
+A patch submission that contains any of the aforementioned 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
+ 5. Announce your RFC to guix-devel@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 is ecommended 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. Publicizing of the RFC on the project's mailing
+list named guix-devel is mandatory, and on other main communication channels
+is highly recommended.
+
+After a number of rounds of review, the discussion should settle and a general
+consensus should emerge. Please follow the "Decision Process" and "Timeline"
+sections.
+
+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
+participants 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
+rfc/withdrawn/.
+
+** 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.
+
+** Timeline
+
+The lifetime of an RFC is structured into the following recommended periods:
+
+ submission (7d) ⟶ comments (30–60d) ⟶ last call (14d) ⟶ withdrawn OR final
+
+The author may withdraw their RFC proposal at any time; and it might be
+submitted again.
+
+*** Submission (up to 7 days)
+
+The author submits their RFC proposal as a regular patch and look for
+co-supporter(s). See 'Co-supporter' section.
+
+Once the RFC is co-supported, it marks the start of a discussion period.
+
+*** Comment (at least 30 days, up to 60 days)
+
+The comment period starts once the author publishes their RFC to guix-devel,
+then the proposal is freely discussed for a period of at least 30 days. It is
+up to the supporter and co-supporter(s) to ensure that sufficient discussion
+is solicited. Please make sure that all have the time and space for
+expressing their comments. The proposal is about significant changes, thus
+more opinions is better than less.
+
+The author is encouraged to publish updated versions of their RFC at any point
+during the discussion period.
+
+Once the discussion goes stale or after 60 days, the author must summarize the
+state of the conversation and keep the final version.
+
+It moves to the last call period.
+
+*** Last call (up to 14 days)
+
+The author publishes a final version of the RFC and a last grace period of 14
+days is granted. People are asked to agree or disagree by commenting:
+
+ - +1 / LGTM: I support
+ - =0 / LGTM: I will live with it
+ - -1: I disagree with this proposal
+
+At least half of people with commit acces must express their voice with the
+keys above during this last call. We need to be sure that the RFC had been
+read by people committed to take care of the project, since it proposes an
+important change.
+
+When a positive consensus is reached, the RFC becomes effective. If not, the
+proposal is archived and the statu quo continues.
+
+
+** 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
+
+Once a consesus is made, a committer should do the following to merge the RFC:
+
+ 1. Fill in the remaining metadata in the RFC header, including links for the
+ original Debbugs submission.
+ 2. Commit everything.
+ 3. Announce the establishment of the RFC to all.
+
+** Template of RFC
+
+The structure of the RFC is captured by the template; see the file
+rfc/0000-template.txt. Please use Markdown as markup language.
+
+** Backward Compatibility
+
+None.
+
+** Forward compatibility
+
+The RFC process can be refined by further RFCs.
+
+** 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: 93e1586116f39a30ba1fcb67bd839a43533dfaf4
--
2.45.2
