Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi,

Well, more than 7 weeks later… Hum, does it mean that the Guix project
is not interested in formalizing some RFC?

WDYT about the proposal?

On Tue, 31 Oct 2023 at 12:14, Simon Tournier <zimon.toutoune@gmail.com> wrote:
> Hi,
>
> This is a proposal for implementing Request-For-Comment process.
> Comment are welcome in #66844 [1]:
>
>     1: https://issues.guix.gnu.org/issue/66844
>
>
> The proposal is highly inspired by Rust RFC:
>
>     https://github.com/rust-lang/rfcs
>
> and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
> on my understanding of Guix community interactions, I write down this
> text; below the text for easing the reading.
>
> Cheers,
> simon
>
> 1: https://github.com/ghc-proposals/ghc-proposals
> 2: https://github.com/NixOS/rfcs
>
> --
>
> RFC process
> ===========
>
> # -*- 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

Cheers,
simon