From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id UD/9GMUueGed0gAAqHPOHw:P1 (envelope-from ) for ; Fri, 03 Jan 2025 18:39:01 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id UD/9GMUueGed0gAAqHPOHw (envelope-from ) for ; Fri, 03 Jan 2025 19:39:01 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=A50B+ouB; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735929541; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Dr8M05BHoJZ397WBCP0aT3OYEQdb1gIQr67uAtbwwZ4=; b=MQTBg6NHzc3bX+SPcNH/QRXlKisCwmV69P6wgmFEYY4zHlaGNeEtmcaPabX/kByHqWeaTL 6pieeqm4gx1vZrYpjkangJ5xKzBGWi7X0z+QOnRYNRrjLscUyrV8r4APGqgg0Uuu07iUyC 8Ym1bkYKORYn2oaG4csqLqJYV+QoPv7hLrq89hJpySJ1B6ZLn5K4cjQjZx55WLvCU4Oj2a 14CGnpGtz+YQhj8yR9yF+DfC94+hnW6mUKxNe9t+78z2zlrrN3TKQpP2/8imJSobiQAN7v wSHdt4aLWBvDKkNNcmgBKKF10qOAeMhUxo/HmYC3uicWylKG646eD2eyFY8cwA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=A50B+ouB; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735929541; a=rsa-sha256; cv=none; b=oVzvNusGD4zII1ri8PJ70pnO0Y6HYP2iky8fRw8GzO2mv9ECnCpqGJKXag+riQw5KMA32Q Pys7GfDWk+lUC9vs8uVOA/zuA75H587dJ2Rzv31PmHqvomtyhUU1v4HCTcGbyzwEcidUEb DtunhcXSdMhkylE4ZGXmgAdJywhARKiecpdclhHJcmRHrQdzRU9dKYQg/L71R/NtMKD7V3 afGQc1nTf8048nVglSdtmflNr4duzk/FyRdj0p4HO6JVzw8Whx/+RR8himhhCXd880XXab PxOjngEVq6r4IDK5jPjb4so8GYxzlWkgTK04X6Pv9ccyR6WP/4J8eU/0z0FFVQ== 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 332AB1B488 for ; Fri, 03 Jan 2025 19:39:01 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTmYr-0007r8-LT; Fri, 03 Jan 2025 13:38:17 -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 1tTmYp-0007qY-AK for guix-devel@gnu.org; Fri, 03 Jan 2025 13:38:15 -0500 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tTmYj-0004X1-Nc; Fri, 03 Jan 2025 13:38:12 -0500 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3862b364538so7186164f8f.1; Fri, 03 Jan 2025 10:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735929487; x=1736534287; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Dr8M05BHoJZ397WBCP0aT3OYEQdb1gIQr67uAtbwwZ4=; b=A50B+ouBARAc9zYyyzdIhPmfjpJY+mRkyZr7+vMBkGOlp/Pd1zP8nNOTSsPPis2YhR xdRu4xeWJLomCy6rEIZJ8qPV4Mc4MrZayQjk9uLsXTIsS0M2P9JA6ZM0E+itbbxhcdf/ EaS0MForaHFVoBNkCxmbc9Zf4+44qAV3WfGNb646zRO1UYiZ6aYwMF0KstVTTjsEfqMx 5PXpIRgsgyPGzqDmDU+PRMIcMaFjQus6FOLgIY3SVwfU3bsER7lzjy/78eiSYBPsh2Pr VGnL5FjrhGXa1qg77YYYMAxKc4FEHi9GXskVV2kG0PTfisWRIzyLmREDroHVQl2Awd+m TKAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735929487; x=1736534287; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Dr8M05BHoJZ397WBCP0aT3OYEQdb1gIQr67uAtbwwZ4=; b=PsdeOJN/WJyyOxuiloC5+rYGR7cnkJeQnbZr4NGzuJzIW/nNe3diZZRAAeaRjSsrFP rrobeTm48q5BoBHOYFmI6KOiYicKt3lTiKGrsJkHGtkBExuyWJQPJOsmr+/gRdrChIC8 WiQw/earKBaJEsjHiQW5XIxo+jKFCeSr9USTS5VQxH7ZYCM1FxSd++HZC7maunF2wXRR Imc+4nsfl7G3dfmrpbI5ZXMhqmapopbfS90S4oFnWQ2aHXfzrDOuI7DaDOSA42qCiinr vtPcTEdGikElZEH3YhxMDyHD3gthWsw9z7LcqxWXaUVeb8Uk+BaKdoTMeXp5MSw4e6CW bdIQ== X-Forwarded-Encrypted: i=1; AJvYcCUxREbR8aZWihOBatt47tObsxqjTYOSNcUaZflxLTxDxVEEn+jwkpMvzBhYNeVODwCyBtduwpVh8LO+nLVK3gwc@gnu.org X-Gm-Message-State: AOJu0Yxm1G2VSG7qX+yGTUmULcBHLADw4MKYZpwF/4HJCtckhGMF0+Ps uk5rsrsCA3pA4Rszfc+7omMziIi8Sz+GEMLDJSAPZCf7PDsvtHd/5+lPTA== X-Gm-Gg: ASbGncsNAXAcEoGL/LBzL+e0R4xzzpxr6yEhINUBsIVAn4DJxhG4viKNL1guuYb1lXJ Xhv0i+Wh2dyxT7IU55+618l0UQepDTl9QyCT3wZJew1/OczLeD+jYeEM8D0Jz6hTeQCPV3BuQ3l tXlDJgrLMRyOMA8sjB1x9pKhwD8z0he2KasfbhUfNsbORVRKRAJ13A3eVm8524taR4qHm9DsZ+M kKPf74M0PkAvMaKBjUslm+fOJfdHjc73QzorDdX6bwq/7hOlIoixpAmwZ064jhCQt4dHmynGHhc pvcZZgDyfmRYCg+PmiVqEtilCda+ecqVL9bvEg5ajQ== X-Google-Smtp-Source: AGHT+IFZZuzY0ac5C0Xp5mApo5Tyc/DK0OlKTf2I0Rdm1y9gkhp3jpgK7tgEe6jZ8jrJAqjF8g/7VQ== X-Received: by 2002:a5d:5846:0:b0:385:faf5:ebb8 with SMTP id ffacd0b85a97d-38a22a1176emr46295132f8f.7.1735929486831; Fri, 03 Jan 2025 10:38:06 -0800 (PST) Received: from lili (roam-nat-fw-prg-194-254-61-40.net.univ-paris-diderot.fr. [194.254.61.40]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a2311b3c8sm38443394f8f.25.2025.01.03.10.38.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 10:38:05 -0800 (PST) From: Simon Tournier To: Guix Devel Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Efraim Flashner , Ricardo Wurmus , Christopher Baines , GNU Guix maintainers Subject: Request-For-Comment process: concrete implementation (v5) In-Reply-To: <87h6m7yrfh.fsf@gmail.com> References: <87h6m7yrfh.fsf@gmail.com> Date: Fri, 03 Jan 2025 19:38:01 +0100 Message-ID: <87ttafn3p2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -4.76 X-Spam-Score: -4.76 X-Migadu-Queue-Id: 332AB1B488 X-TUID: WLU56pri4Pmt Hi, Below the updated version (v5) of the RFC introducing the RFC process. The submission is: . Well, a very good lesson is: Co-supporter is very important! It helps in crossing the final line. :-) In other words, the Timeline had not been respected at all because the lack of an initial Co-supporter. Almost two months ago, No=C3=A9 resumed the proposal [1]. It appears to me that now we are close to the end of the Comment period. Yeah any comment is very welcome. :-) Then, I propose to start the Last Call the 17th (January) and finalize (or withdraw) for the end of the month (January, 31th) =E2=80=93 in both ca= ses, a good opportunity to share a drink at Guix Days in Brussels. :-) WDYT? Cheers, simon 1: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process. No=C3=A9 Lopez via Guix-patches via Sun, 08 Dec 2024 13:29:52 +0100 id:cover.1733614983.git.noelopez@free.fr https://issues.guix.gnu.org/74736 https://issues.guix.gnu.org/msgid/cover.1733614983.git.noelopez@free.fr https://yhetil.org/guix/cover.1733614983.git.noelopez@free.fr -- title: Request-For-Comment process Issue: 66844 Status: pending Supporter: Simon Tournier Co-supporters: No=C3=A9 Lopez date: 2023-10-31 --- # Summary The =E2=80=9CRFC=E2=80=9D (request for comments) process is intended to pro= vide a consistent and structured path for major changes to enter the Guix project, so that all stakeholders can make decisions collectively and be confident about the direction it is evolving in. # Motivation Guix becomes a broadly used system with many contributors and the way we add new features has been good but starts to show its limits. The lack of a cl= ear process easy to consult makes difficult to share a common evolution. 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 =E2=80=9Csignificant=E2=80=9D means an= y 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 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.) # Detailed design ## When to follow this process This process is followed when one intends to make =E2=80=9Csignificant=E2= =80=9D changes to the Guix project. What constitutes a =E2=80=9Csignificant=E2=80=9D change 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 or 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=E2=80=99t break interfaces A patch submission that contains any of the aforementioned substantial chan= ges may be asked to first submit a RFC. For general day-to-day contributions, please follow the regular process as described by the manual, for example sections =E2=80=9CSubmitting Patches= =E2=80=9D, =E2=80=9CReviewing the Work of Others=E2=80=9D, =E2=80=9CTeams=E2=80=9D and =E2=80=9CMaking De= cisions=E2=80=9D. ## How the process works 1. Clone 2. Copy rfc/0000-template.md to rfc/00XY-good-name.md 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 RFC proposal is as well-written as you would expect the final version of it to be. It does not mean that all the subtleties must be considered at this point since that is the aim of Comment period. It means that the RFC process is not a prospective brainstorming and the RFC proposal formalize an idea for making it happen. The submission of a RFC proposal does not require an implementation. Howev= er, to improve the chance of a successful RFC, it is recommended to have an idea for implementing it. If an implementation is attached to the detailed desi= gn, it might help the discussion. At this point, at least one other person must volunteer to be =E2=80=9Cco-s= upporter=E2=80=9D. The aim is to improve the chances that the RFC is both desired and likely to be implemented. See =E2=80=9CCo-supporter=E2=80=9D section. Once supporter and co-supporter(s) are committed in the RFC process, the discussion starts. Publicizing of the RFC on the project=E2=80=99s mailing= list named guix-devel is mandatory, and on other main communication channels is highly recommended. After a number of rounds of comments, the discussion should settle and a general consensus should emerge. Please follow the =E2=80=9CDecision Makin= g=E2=80=9D and =E2=80=9CTimeline=E2=80=9D sections. A successful RFC is not a rubber stamp, and in particular still does not me= an the feature will ultimately be merged; it does mean that in principle all t= he 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 =E2=80=9Clet's discuss again with a= different angle=E2=80=9D. The last state of an unsuccessful RFC is archived under the= directory rfc/withdrawn/ and the status quo continues. When time passing, a successful RFC might be replaced by another successful RFC. The status of the former is thus modified and becomes 'deprecated'; it is archived under the directory rfc/deprecated. At the end of the process, the status of the RFC is either successful, withdrawn or deprecated. ## 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 team member = or a contributor with commit access. The co-supporter helps the supporter, th= ey are both charged with keeping the RFC moving through the process. The co-supporter role is to help the RFC supporter by being the timekeeper and helps in pushing forward until process completion. The co-supporter doesn=E2=80=99t necessarily have to agree with all the poi= nts 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: digraph "RFC Timeline" { submission[label=3D7=C2=A0days>] comments[label=3D30=E2=80=9360=C2=A0days>] last_call[label=3D14=C2=A0days>] withdrawn[label=3DWithdrawn, shape=3Drectangle] final[label=3DFinal, shape=3Drectangle] =20=20=20=20 submission -> comments submission -> withdrawn comments -> last_call last_call -> withdrawn last_call -> final =20=20=20=20 withdrawn -> submission [label=3D"New version"] =20=20=20=20 comments -> withdrawn } The author may withdraw their RFC proposal at any time; and it might be submitted again using a new issue number. ### Submission (up to 7 days) Anyone might be author and submits their RFC proposal as a regular patch and look for co-supporter(s). See =E2=80=9CCo-supporter=E2=80=9D section. Once the RFC proposal is co-supported, it marks the start of a Comment peri= od. ### Comment (at least 30 days, up to 60 days) The Comment period starts once the author publishes their RFC to guix-devel, then the RFC is freely discussed by anyone 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 RFC is about significant changes, thus more opinions is bett= er than less. The author is encouraged to publish updated versions of their RFC at any po= int 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) Once the final version is published, team members have 14 days to cast one = of the following replies on the patch-tracking entry about the RFC: - Support: meaning that support in principle; - Accept: meaning no opposition in principle; - Disagree: meaning opposed in principle. This deliberation period strengthens the consensus; see =E2=80=9CDecision M= aking=E2=80=9D. The RFC is accepted if (1) at least 25% of the team members cast a reply, a= nd (2) no one disagrees. In other cases, the RFC is withdrawn. Anyone who is on a team (see file =E2=80=98teams.scm=E2=80=99) is a deliber= ating member and is asked to reply. ## Decision Making It is expected from all contributors, and even more so from team members, to help in building 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 wishing to block a proposal bears a special responsibility for finding alternatives, proposing ideas/code or explaining the rationale for = the status quo. As a deliberating member, when replying =E2=80=9CDisagree=E2=80=9D, you mea= n (1) you cannot live with the RFC and (2) you have been active and helping in discussing the RFC during the Comment period. To learn what consensus decision making means and understand its finer details, you are encouraged to read . ## Merging the outcome Once a consensus 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 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.md. Please use Markdown as markup language. ## The Cost Of Reverting The RFC process can be refined by further 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. 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=E2=80=99t want the process to become unduly burdensome. This = is a careful balance which will require care to maintain moving forward.