From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id SDrJIolZfGc8RQAA62LTzQ:P1 (envelope-from ) for ; Mon, 06 Jan 2025 22:30:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id SDrJIolZfGc8RQAA62LTzQ (envelope-from ) for ; Mon, 06 Jan 2025 23:30:33 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b="s/BsAEnU"; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b=fmmvWnT8; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1736202633; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=ofhXmokdSszedHpm/yzWtMTsJI+3lywVOHXmmNNM180=; b=sMuBcC1Zj0Vkn7/X+KH/K+q/pL12CiXr9uTjO7k4eUt12X6eGqQHpWWVvb3dqWTY7z+ONT 8xTzJN2+SDkYkIgpf9dNciUKmAwFKcxLcPzhUfzclCBbrgMa5i/DYGZi5des/DDUrOZN+5 8U/D5Q+oTsplhFmwSvwLNsOQO8koOVxpe9hpUWHUXGttTliXmebi/QavO2L5lf3a4EGKeF K6bm3+sk0vOwxWUK36tDLIGLN+4SFoSvCT6MWWfrviP+XcTzC4COxFUA27p9pirr6GuEua LPlrl24nTeHu71Qj0BHfMJ5zN04BoRBzoIT0v0OZqToVPOEvh5SIskQxphP48Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b="s/BsAEnU"; dkim=fail ("headers rsa verify failed") header.d=gnu.org header.s=fencepost-gnu-org header.b=fmmvWnT8; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1736202633; a=rsa-sha256; cv=none; b=gYI+dwRd3uR55C5RqX/hBoBytuJc46gq2gKacb9xM1ObqI/mcIYN+xpMBMfa8pK61wNQjL keZq22hZi0oSwVsvIPqgt0FqeZHTiAFckLoBNrJ8yaoi4/Ruk/h4NzUggEBYSJFU/TdmNv +M2lGJQPi3bnq06DjXQKL7o6ePFJ+m6xoclOhfRkC9fVXkJVZgq0GMyEkv4ME1sU7f1x5p RMddQ4/6cBe/5rfB4CTGNnANEx8fpDd6PLtSDiV3dik6/XZP26BFZ9AcSBDUz41ZP8AXFw Ylg3KSbxHxFHT2LcJ7W58wCMsv1mLMvFQKGrUoL2Vn+txtAs0QG9GDWUjlV5Kw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 22E9D5249F for ; Mon, 06 Jan 2025 23:30:33 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUvbq-0003Hw-9b; Mon, 06 Jan 2025 17:30:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUvbm-0003FF-Va for guix-patches@gnu.org; Mon, 06 Jan 2025 17:30:03 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUvbm-0001hY-AW for guix-patches@gnu.org; Mon, 06 Jan 2025 17:30:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=ofhXmokdSszedHpm/yzWtMTsJI+3lywVOHXmmNNM180=; b=s/BsAEnU2zvhAZMTw0kv4FbyQ/eP2XZoI7YPMzPHDBOzpst7rEIKTiIk+YXI23OW8Lx0bsaltemw//BPyTtb07fbkBNv2tRhE5UmW1lNetavW/GzrDeArAq7Jh7lBjZUk1M4TjAr6VkwTHIskkynMvSN5MMtJ1g2XieS1oHfhe8Rk+XYDsdFJIuMsSnYYAOmtchEGb/qHK9V09C6nAAD18i+o/UsDBqbKaJx2jAjIRmKAp6e1H/h/efntO/DU/AU2ogC0Mbm0P9Vf7HpPDzEyjRoAdlsDn5FMmX/fb//qj1N/Vry/Ekk8eCeLCQQjHTJ6Ob51gI8FHPb7jiXqcfLow==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUvbm-000771-58 for guix-patches@gnu.org; Mon, 06 Jan 2025 17:30:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#74736] [PATCH v6] Add Request-for-Comments process. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 06 Jan 2025 22:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74736 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 74736@debbugs.gnu.org Cc: =?UTF-8?Q?No=C3=A9?= Lopez , =?UTF-8?Q?No=C3=A9?= Lopez , Christopher Baines , Simon Tournier Received: via spool by 74736-submit@debbugs.gnu.org id=B74736.173620257927272 (code B ref 74736); Mon, 06 Jan 2025 22:30:02 +0000 Received: (at 74736) by debbugs.gnu.org; 6 Jan 2025 22:29:39 +0000 Received: from localhost ([127.0.0.1]:40899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUvbO-00075o-H8 for submit@debbugs.gnu.org; Mon, 06 Jan 2025 17:29:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58308) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUvbL-00075W-MA for 74736@debbugs.gnu.org; Mon, 06 Jan 2025 17:29:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUvbD-0001ek-Bk; Mon, 06 Jan 2025 17:29:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ofhXmokdSszedHpm/yzWtMTsJI+3lywVOHXmmNNM180=; b=fmmvWnT8XyARQvsM2zkF uQF5nKSIPZCpcLKh4hjjbdXSPQ1jPx0fpRlyRi3mqg1ct7IFrYdCvWfNF5fJQ30DV72NwyoxNLViz JXi+WyrC4nCdsVLtmagvlM/Ej4wb5Gv50JvaqLdFmwv4rVRSJzlK779jvNVqp5iIAMK5QS0xaeK6h ZOFZgZ0tjD5eN0+1/HpC0d7E+YyISILb4BG0jIC82E9/EYRB/n+gtDVCrVg78A2a8FW40F/s77A8c OcfP21wr+X7ue8zagtkaTDoEZgZaJtzXfS4pfos4RCUt7ZhnwZMR2EEdRjjgJjk/Mv9NNCzRt87tC oV30lHGwtlhjcw==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: (Simon Tournier's message of "Fri, 3 Jan 2025 19:14:40 +0100") References: Date: Mon, 06 Jan 2025 23:29:21 +0100 Message-ID: <87y0zn4lvi.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 22E9D5249F X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: 0.32 X-Spam-Score: 0.32 X-TUID: n1NUluKL5chk --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, As proposed before, here=E2=80=99s a reworked version based on v5. The int= ent is to keep the spirit and process unchanged compared to v5, while making the document a bit more concise (239 lines, v5 was 322), improving consistency for key words, hopefully improving wording, fixing grammatical issues, and adding Markdown ornaments where appropriate. Notable changes: =E2=80=A2 Instead of =E2=80=9Csupporter=E2=80=9D and =E2=80=9Cco-supporte= r=E2=80=9D, I propose =E2=80=9Cauthor(s)=E2=80=9D and =E2=80=9Csupporter(s)=E2=80=9D (there must be at least one supporter). =E2=80=A2 Explicitly state the license of RFCs (CC-BY-SA or GFDL). =E2=80=A2 Clarify that the deliberation period lasts exactly 14 days (was= =E2=80=9Cup to 14 days=E2=80=9D in one place, =E2=80=9C14 days=E2=80=9D in another). =E2=80=A2 Consistently name the different periods. =E2=80=A2 Remove mention of the =E2=80=98withdrawn/=E2=80=99 directory: i= t=E2=80=99s redundant with the =E2=80=98status=E2=80=99 header. =E2=80=A2 Clarify what to do with =E2=80=9Cdeprecated=E2=80=9D RFCs. =E2=80=A2 Clarify headers of this RFC. =E2=80=A2 Clarify that this is not just for technical changes. =20=20 I can proofread and possibly propose minor tweaks the template afterwards. Thoughts? Ludo=E2=80=99. --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename=rfc-v6.md Content-Transfer-Encoding: quoted-printable title: Requests-for-Comment Process id: 000 status: submitted discussion: https://issues.guix.gnu.org/74736 authors: Simon Tournier, No=C3=A9 Lopez, Ludovic Court=C3=A8s supporters: ? submitted: 2024-12-12 date: 2025-01-15 --- # Summary This document describes the _request for comments_ (RFC) process of the Guix project. The RFC process is intended to provide a consistent and structured way to propose, discuss, and decide on major changes affecting the project. It aims to draw attention of community members on important decisions, technical or not, and to give them a chance to weigh in. # Motivation Day-to-day work on Guix revolves around informal interactions, peer review, and consensus-based decision making. As the community grows, so does the stream of proposed changes, and no single person is able to keep track of all of them. The RFC process is a mechanism to determine whether a proposed change is =E2=80=9Csignificant=E2=80=9D enough to require attention from the communit= y at large and if so, to provide a documented way to bring about broad community discussion and to collectively decide on the proposal. A change may be deemed =E2=80=9Csignificant=E2=80=9D when it could only be = reverted at a high cost or, for technical changes, when it has the potential to disrupt user scripts and programs or user workflows. Examples include: - changing the `` record type and/or its interfaces; - adding or removing a `guix` sub-command; - changing the channel mechanism; - changing project governance 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.) # Detailed Design ## When to Follow This Process The RFC process applies only to =E2=80=9Csignificant=E2=80=9D changes, whic= h include: - 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; - significant project infrastructure or workflow changes; - governance or changes to the way we collaborate. Someone submitting a patch for any such change may be asked to submit an RFC first. Most day-to-day contributions do *not* require an RFC; examples include: - adding or updating packages, removing outdated packages; - fixing security issues and bugs in a way that does not change interfaces; - updating the manual, updating translations; - changing the configuration of systems part of project infrastructure in a user-invisible way. These day-to-day contributions remain governed by the process described by the manual in its =E2=80=9CContributing=E2=80=9D chapter. ## How the Process Works 1. Clone https://git.savannah.gnu.org/git/guix/requests-for-comments.git . 2. Copy `0000-template.md` to `00XY-short-name.md` where `short-name` is a short descriptive name long and `XY` is the sequence number. 3. Write your RFC following the template=E2=80=99s structure. The RFC must= not be prospective; it must formalize an idea and sketch a plan to implement it, even if not all details are known. If it intends to deprecate a previously-accepted RFC, it must explicitly say so. 4. Submit the RFC as a patch to `guix-patches@gnu.org`. 5. Announce your RFC at `guix-devel@gnu.org` and look for *supporters*: one or more people who will support the RFC and participate in discussions by your side (see below). The RFC is *submitted* once it has at least one supporter in addition to the author(s). ## Supporters A supporter is a contributor sufficiently familiar with the project=E2=80= =99s practices, hence it is recommended, but not mandatory, to be a team member. Supporters do not 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. Supporters help the author(s) by participating in discussions, amending the document as it is being discussed, and acting as timekeepers. ## Timeline The lifetime of an RFC is structured into the following recommended periods: ![diagram.svg](Diagram of the RFC process.) ```dot <- TODO: make this a separate file digraph "RFC Timeline" { submission[label=3Dup to 7=C2=A0days>] comments[label=3D30=E2=80=9360=C2=A0days>] deliberation[label=3D14=C2=A0days>] withdrawn[label=3DWithdrawn, shape=3Drectangle] final[label=3DFinal, shape=3Drectangle] =20=20=20=20 submission -> comments submission -> withdrawn comments -> deliberation deliberation -> withdrawn deliberation -> final =20=20=20=20 withdrawn -> submission [label=3D"New version"] =20=20=20=20 comments -> withdrawn } ``` The subsections below detail the various stages and their duration. ### Submission Period (up to 7 days) Anyone can author and submit an RFC as a regular patch and look for supporters (see below). The RFC is *submitted* once it has one or more supporters; the next step is the *discussion period*. Author(s) may withdraw their RFC at any time; they can resubmit it again later, possibly under a new RFC number. ### Discussion Period (at least 30 days, up to 60 days) Once submitted, the RFC is publicly discussed; authors are encouraged to publish updated versions incorporating feedback during the discussion. Once the discussion settles, at the latest after 60 days, the author(s) publish a final version, leading to the *deliberation period*. ### Deliberation Period (14 days) All members of any team of the Guix project can participate in deliberation and are encouraged to do so. Once the final version is published, team members have 14 days to send one of the following replies on the patch-tracking entry of the RFC: - =E2=80=9CI support=E2=80=9D, meaning that one supports the proposal); - =E2=80=9CI accept=E2=80=9D, meaning that one consents to the implementati= on of the proposal; - =E2=80=9CI disapprove=E2=80=9D, meaning that one opposes the implementati= on of the proposal. A team member sending this reply must have actively proposed alternative solutions during the discussion period. The RFC is *accepted* if (1) at least 25% of all team members send a reply, and (2) no one disagrees. In other cases, the RFC is *withdrawn*. Deliberation aims at consolidating consensus; see =E2=80=9CDecision Making= =E2=80=9D below. RFC acceptance is not a rubber stamp; in particular, it does not mean the proposal will effectively be implemented, but it does mean that all the participants consent to its implementation. Similarly, withdrawal does not necessarily equate with rejection; it could mean that more discussion and thought is needed before ideas in the RFC are accepted by the community. ## Decision Making Contributors and even more so team members are expected to help build consensus. By using consensus, we are committed to finding solutions that everyone can live with. Thus, no decision is made against significant concerns; these concerns are actively resolved through counter proposals. A deliberating member disapproving a proposal bears a responsibility for finding alternatives, proposing ideas or 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 Final RFCs Whether it is accepted or withdrawn, a committer merges the final RFC following these steps: 1. filling in the remaining metadata in the RFC headers (changing the `status` to `accepted` or `withdrawn`; adding the URL of the discussion in the `discussion` header; updating the `date` header; if previously-accepted RFCs are deprecated by this new RFC, change the `status` header accordingly); 2. committing everything; 3. announcing the publication of the RFC. All the RFCs are dual-licensed under the [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/) license and the [GNU Free Documentation License 1.3, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts](https://www.gnu.org/licenses/fdl-1.3.html). ## RFC Template The expected structure of RFCs is captured by the template in the file `0000-template.md`, written in English with Markdown ornaments. ## Cost of Reverting The RFC process described in this documented can be amended by subsequent RFCs. ## Drawbacks There is a risk that the additional process will hinder contribution more t= han it would help. We should stay alert that the process is only a way to help contribution, not an end in itself. Discussions could easily have a low signal-to-noise ratio. We will collectively pay attention to over- and under-representation of voices and notably avoid repeating arguments, avoid using exclusionary jargon, and solicit opinions of those who remained silent. ## Open Issues There are still questions regarding the desired scope of the process. While we want to ensure that technical changes that affect users are well-considered, we certainly don=E2=80=99t want the process to become undu= ly burdensome. This is a careful balance which will require care to maintain moving forward. --=-=-=--