GNU bug report logs - #74736
[PATCH v2 0/1] Add Request-For-Comment process.

Previous Next

Full log

Message #69 received at 74736 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: 74736 <at> debbugs.gnu.org
Cc: Noé Lopez <noe <at> xn--no-cja.eu>,
 Noé Lopez <noelopez <at> free.fr>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Christopher Baines <mail <at> cbanes.net>,
 Simon Tournier <zimon.toutoune <at> gmail.com>
Subject: [PATCH v5] rfc: Add Request-For-Comment process.
Date: Fri,  3 Jan 2025 19:14:40 +0100

* rfc/0001-rfc-process.md: New file.
* rfc/0000-template.md: New file.

Co-authored-by: Noé Lopez <noe <at> xn--no-cja.eu>
Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
---
 rfc/0000-template.md    |  59 +++++++++
 rfc/0001-rfc-process.md | 257 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 316 insertions(+)
 create mode 100644 rfc/0000-template.md
 create mode 100644 rfc/0001-rfc-process.md

diff --git a/rfc/0000-template.md b/rfc/0000-template.md
new file mode 100644
index 0000000000..a3913335ad
--- /dev/null
+++ b/rfc/0000-template.md
@@ -0,0 +1,59 @@
+title: <The meaningful name of the proposal>
+Issue: <number assigned by Debbugs>
+Status: <pending|successful|withdrawn|deprecated>
+Supporter: <Your Name>
+Co-supporter(s): <Some> <Names>
+date: <date when the process starts>
+---
+
+# 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.
+
+## The Cost Of Reverting
+
+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?
+
+How will your proposed change evolve with time?  What is the cost of changing
+the approach later?
+
+The aim is to explicitely consider beforehand potential Compatibility issues.
+
+# Drawbacks or Open Questions
+
+At submitting time, be upfront and trust that the community will help.
+
+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.
+
+The aim here is to ease when revisiting the topic.  It will help to grasp the
+essentials and invite to read all the discussion.
diff --git a/rfc/0001-rfc-process.md b/rfc/0001-rfc-process.md
new file mode 100644
index 0000000000..adb5365d73
--- /dev/null
+++ b/rfc/0001-rfc-process.md
@@ -0,0 +1,257 @@
+title: Request-For-Comment process
+Issue: 66844
+Status: pending
+Supporter: Simon Tournier
+Co-supporters: Noé Lopez
+date: 2023-10-31
+---
+
+# Summary
+
+The “RFC” (request for comments) process is intended to provide 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 clear
+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 “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.)
+
+# Detailed design
+
+## When to follow this process
+
+This process is followed when one intends to make “significant” changes to the
+Guix project.  What constitutes a “significant” 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’t break interfaces
+
+A patch submission that contains any of the aforementioned substantial changes
+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 “Submitting Patches”, “Reviewing
+the Work of Others”, “Teams” and “Making Decisions”.
+
+## How the process works
+
+1.  Clone <https://git.savannah.gnu.org/git/guix.git>
+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 <at> gnu.org
+5.  Announce your RFC to guix-devel <at> 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.  However,
+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 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.  See “Co-supporter” section.
+
+Once supporter and co-supporter(s) are committed in the RFC process, the
+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 comments, the discussion should settle and a
+general consensus should emerge.  Please follow the “Decision Making” 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/ 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, they
+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’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:
+
+digraph "RFC Timeline" {
+    submission[label=<Submission Period<br />7 days>]
+    comments[label=<Discussion Period<br />30–60 days>]
+    last_call[label=<Deliberation Period<br />14 days>]
+    withdrawn[label=Withdrawn, shape=rectangle]
+    final[label=Final, shape=rectangle]
+    
+    submission -> comments
+    submission -> withdrawn
+    comments -> last_call
+    last_call -> withdrawn
+    last_call -> final
+    
+    withdrawn -> submission [label="New version"]
+    
+    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 “Co-supporter” section.
+
+Once the RFC proposal is co-supported, it marks the start of a Comment 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 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 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)
+
+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 “Decision Making”.
+
+The RFC is accepted if (1) at least 25% of the team members cast a reply, and
+(2) no one disagrees.  In other cases, the RFC is withdrawn.
+
+Anyone who is on a team (see file ‘teams.scm’) is a deliberating 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 “Disagree”, you mean (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
+<https://www.seedsforchange.org.uk/consensus>.
+
+## 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 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.

base-commit: ce3ffac5d366ebf20e0d95779f2fe1ea6dde0202
-- 
2.45.2

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.