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

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

[Noé Lopez via Guix-patches via]

From: Noé Lopez <noelopez@free.fr>

Hi,

It has been more than a year since Simon Tournier’s original patch[1] for
specifying a “request for comment” process.  I believe that such a process can
pave the way for big changes to make their way to Guix and the establishment
of a governance model, among other things.

Therefore, I have taken it upon myself to produce an updated version taking
into account the comments received on the original patch and my own changes.

These changes are targeted not only to committers, but to every contributor so
that anyone can propose important changes.  So anyone should feel free to
comment what they think :)

Have a good day,
Noé Lopez

[1] https://issues.guix.gnu.org/66844

Simon Tournier (1):
  rfc: Add Request-For-Comment process.

 rfc/0000-template.txt    |  76 +++++++++++++
 rfc/0001-rfc-process.txt | 232 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 308 insertions(+)
 create mode 100644 rfc/0000-template.txt
 create mode 100644 rfc/0001-rfc-process.txt


base-commit: 1affd2b5aa7f5467a44cf757c4fc0c6956d3f3c9
-- 
2.46.0

[bug#74736] [PATCH v2 1/1] rfc: Add Request-For-Comment process.

[Noé Lopez via Guix-patches via]

From: Simon Tournier <zimon.toutoune@gmail.com>

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

Co-authored-by: Noé Lopez <noe@xn--no-cja.eu>
Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
---
 rfc/0000-template.txt    |  76 +++++++++++++
 rfc/0001-rfc-process.txt | 232 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 308 insertions(+)
 create mode 100644 rfc/0000-template.txt
 create mode 100644 rfc/0001-rfc-process.txt

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..4282e84230
--- /dev/null
+++ b/rfc/0001-rfc-process.txt
@@ -0,0 +1,232 @@
+# -*- 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 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.  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.
+
+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)
+ + changes in policy (Add "Deprecation Policy", #72840)
+ + 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.
+
+  + 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
+
+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
+  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 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 and other Guix communities are 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
+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.
+
+The Guix projects ensures that a team of co-supporters – the RFC team – remain
+available for any new RFCs that don’t find any co-supporters.  This team
+should be added to the etc/teams.scm file.
+
+** Timeline
+
+The lifetime of an RFC is structured into the following periods:
+  submission (7d) ⟶ comments (30–60d) ⟶ last call (14d) ⟶ withdrawn OR final
+
+*** Submission
+
+The author submits their proposal to the patches mailing list and the RFC team
+which will read the proposal and can advise the author on improving their RFC.
+This first round of review is provided only to help the author and should not
+reflect personal bias or opinions.
+
+If seven days have passed without answer or the author thinks that his
+RFC is ready then he may move on to the comment period.
+
+*** Comment
+
+The author publishes their RFC to guix-devel and starts a discussion period of
+at least 30 days.  It is up to the supporter and co-supporter to ensure that
+sufficient discussion is solicited. Make sure that all have the time for
+expressing their comments.  The proposal is about significant changes, thus
+more time 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 should publish or
+keep their final version and move into the last call period.
+
+*** Last call
+
+The author publishes a final version of the RFC and a 14 day period is given
+for people to express their agreement or disagreement.  If a positive
+consensus is reached the RFC becomes final and the changes should be applied
+in less than six months.
+
+If no consensus can be reached or the changes were not applied in less than
+six months, the RFC becomes withdrawn and is archived.  The author may also
+withdraw their RFC at any point.
+
+** 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 the stakeholders.
+ 4. Ensure the RFC is applied within six months.
+
+** Template of RFC
+
+# Ludovic Courtès:
+# I’d go for one format, preferably Markdown because we have a library to
+# parse it.
+
+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.
+
+** 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
-- 
2.46.0

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

[Ludovic Courtès]

Hi Noé,

Thanks a lot for resuming this work!  That’s the right thing to do.

Leaving out 000-rfc-template.txt for now.

Noé Lopez <noe@noé.eu> skribis:

> +++ b/rfc/0001-rfc-process.txt
> @@ -0,0 +1,232 @@
> +# -*- mode:org -*-
> +#+TITLE: Request-For-Comment process
> +#+DATE: 2023-10-31

[...]

> +* 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.

“… to achieve consensus, lack of a central place to consult contributors
and users, and lack of clear deadlines.”

> +Note that this process does not cover most of the changes.  It covers
> +significant changes, for some examples:

“It covers proposals 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: ”

> + + 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)
> + + changes in policy (Add "Deprecation Policy", #72840)
> + + collaboration via team and branch-features
> +   (several places mailing list guix-devel)

These are changes from the past that may long be forgotten by the time
we read them.  Perhaps we can abstract it a bit, like:

  - 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.)

This list seems redundant with and similar to that under “When To Follow
This Process”; maybe just keep it in one place, under “When To Follow…”?

> +* Detail design

“Detailed Design”

> +** When you need to follow this process

“When 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.
> +
> +  + 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

I would add “General day-to-day contributions follow the regular
[decision-making process] and [team organization].”, with references to
the relevant sections of the manual.

> +A patch submission to Debbugs that contains any of the afore-mentioned

Typo: “aforementioned”.

I would remove “to Debbugs” to keep it more general and future-proof.

> +** How the process works
> +
> +  1. Clone https://git.savannah.gnu.org/git/guix.git

I would suggest a separate repo.

> +  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 might be recommended to have an

s/it might be/it is/

> +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 and other Guix communities are recommended.

“Publicizing of the RFC on the project’s main communication channels is
mandatory.”

> +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.

I’d drop it or write “See the ‘Decision Process and Timeline’ section
below.”

> +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.

I’d write “all the participants” instead of “all the major
stakeholders”.

> +The Guix projects ensures that a team of co-supporters – the RFC team – remain
> +available for any new RFCs that don’t find any co-supporters.  This team
> +should be added to the etc/teams.scm file.

I would drop that.

> +** Timeline
> +
> +The lifetime of an RFC is structured into the following periods:
> +  submission (7d) ⟶ comments (30–60d) ⟶ last call (14d) ⟶ withdrawn OR final

Let’s borrow from the state transition diagram from at
<https://srfi.schemers.org/srfi-process.html>, for clarity.

Perhaps we should also shorten the text of each section below.

In each section heading, I would add its duration:

  *** Submission (up to 7 days)

  …

  *** Discussion (at least 30 days, up to 60 days)

  …

> +*** Comment
> +
> +The author publishes their RFC to guix-devel and starts a discussion period of

“The author publicizes their RFC, marking the start of a discussion
period of at least 30 days and at most 60 days.”

> +*** Last call
> +
> +The author publishes a final version of the RFC and a 14 day period is given
> +for people to express their agreement or disagreement.  If a positive
> +consensus is reached the RFC becomes final and the changes should be applied

“If consensus is reached, the RFC becomes …”

> +in less than six months.

I’m not sure what “the changes” refers to.

Regarding consensus, I would add a link to the “Making Decisions”
section of the manual…

> +** Decision making: consensus

… and drop this.

> +** 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 the stakeholders.
> + 4. Ensure the RFC is applied within six months.

Maybe we should define the role of “RFC editors” (or “RFC team”?), which
would be the people responsible for doing those changes.

> +** Template of RFC
> +
> +# Ludovic Courtès:
> +# I’d go for one format, preferably Markdown because we have a library to
> +# parse it.

Yes! :-)  Despite being an Org fan, I think we should stick to Markdown:
it’s widespread, well-known, and can be rendered by Haunt or by any
forge.

> +** Backward Compatibility
> +
> +None.
> +
> +** Forward compatibility

I’m not sure what’s expected in these sections.  Maybe “Compatibility
Considerations” would be more appropriate?

> +** 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

I think these two sections in the context of this foundational document
look a bit ridiculous.  :-)  But maybe that’s okay?

Thanks!

Ludo’.

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

[Simon Tournier]

Hi all,

Thanks Noé!  I added you as co-supporter; someone definitively
required. ;-)

Thanks Steve for reaching me some weeks end ago.

Well, based on Noé’s v2, I polished some comments and sent v3; based on
what my follow up started weeks (months?) ago.


On Thu, 12 Dec 2024 at 19:14, Ludovic Courtès <ludo@gnu.org> wrote:

> These are changes from the past that may long be forgotten by the time
> we read them.  Perhaps we can abstract it a bit, like:
>
>   - 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.)
>
> This list seems redundant with and similar to that under “When To Follow
> This Process”; maybe just keep it in one place, under “When To Follow…”?

I think it helps to understand.  Concrete examples always help, IMHO.

Therefore, I propose what your wording.  Then, past examples where this
RFC process would have been helpful, I guess.

>> +  1. Clone https://git.savannah.gnu.org/git/guix.git
>
> I would suggest a separate repo.

Bah since we are putting all there… When you see etc/ ;-)


>> +** Decision making: consensus
>
> … and drop this.

I think it makes more sense to have the Decision Making as RFC and then
the manual refers to it, and not the converse. ;-)

Therefore, I would keep the section here.  And once we are done, letting
the manual as-is, I would link to RFC.

What defines the Decision Making *is* RFC and not the manual. ;-)


> Maybe we should define the role of “RFC editors” (or “RFC team”?), which
> would be the people responsible for doing those changes.

I’ve drop this “RFC teams“ or “RFC editors” because in my initial idea,
this is the aim of “co-supporter(s)”.  See the relevant section; does it
need to be improved?


>> +** Backward Compatibility
>> +
>> +None.
>> +
>> +** Forward compatibility
>
> I’m not sure what’s expected in these sections.  Maybe “Compatibility
> Considerations” would be more appropriate?

Yes, maybe “Compatibility Consideration”.  It needs to be in agreement
with the template.

>> +* Unresolved questions
>
> I think these two sections in the context of this foundational document
> look a bit ridiculous.  :-)  But maybe that’s okay?

I think that the first RFC must respects what it asks to other RFC. ;-)

And if the consensus is not reached, we need a place to summarize the
unresolved discussion, no?


Again, thanks Noé and Steve for taking care of that!

Cheers,
simon

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

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

>>> +** Decision making: consensus
>>
>> … and drop this.
>
> I think it makes more sense to have the Decision Making as RFC and then
> the manual refers to it, and not the converse. ;-)
>
> Therefore, I would keep the section here.  And once we are done, letting
> the manual as-is, I would link to RFC.
>
> What defines the Decision Making *is* RFC and not the manual. ;-)

Earlier, I wrote:

> I would add “General day-to-day contributions follow the regular
> [decision-making process] and [team organization].”, with references to
> the relevant sections of the manual.

Since (1) day-to-day contributions do not follow the RFC process and (2)
teams and consensus-based decision making are already defined (and went
through peer review), I think it makes more sense to build on these two
sections we already have.

>>> +* Unresolved questions
>>
>> I think these two sections in the context of this foundational document
>> look a bit ridiculous.  :-)  But maybe that’s okay?
>
> I think that the first RFC must respects what it asks to other RFC. ;-)
>
> And if the consensus is not reached, we need a place to summarize the
> unresolved discussion, no?

I already mentioned it back in February, FWIW:
<https://issues.guix.gnu.org/66844#3-lineno186>.

Anyway, no big deal, but it will certainly look strange eventually.

Ludo’.

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

[Simon Tournier]

Hi Ludo,

I agree (more than less) with all the other comments except this
one. :-)


>>>> +** Decision making: consensus
>>>
>>> … and drop this.
>>
>> I think it makes more sense to have the Decision Making as RFC and then
>> the manual refers to it, and not the converse. ;-)
>>
>> Therefore, I would keep the section here.  And once we are done, letting
>> the manual as-is, I would link to RFC.
>>
>> What defines the Decision Making *is* RFC and not the manual. ;-)
>
> Earlier, I wrote:
>
>> I would add “General day-to-day contributions follow the regular
>> [decision-making process] and [team organization].”, with references to
>> the relevant sections of the manual.
>
> Since (1) day-to-day contributions do not follow the RFC process and (2)
> teams and consensus-based decision making are already defined (and went
> through peer review), I think it makes more sense to build on these two
> sections we already have.

I still think the RFC process must contain its own “Decision Making”
process and must not refer to external parts that could be changed
without going via this RFC process.

Somehow, from my point of view, it makes more sense to encode “Decision
Making” or “Commit Access” or “Teams” via future RFCs than via sections
in the manual.  And we need to bootstrap the “Decision Making”, no?

For sure, I agree that we do not build from nothing.  To me, this very
first RFC makes explicit the structure we already have.  Maybe I
misunderstand something, IMHO, we should avoid the temptation to say:
Hey we already have a way to collaborate thus let implicitly rely on.

Hum? 🤔 Somehow, I would find the RFC process incomplete without an
explicit self-contained “Decision Making” section.

What do you think?  What do people think?

Cheers,
simon

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

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

>> Since (1) day-to-day contributions do not follow the RFC process and (2)
>> teams and consensus-based decision making are already defined (and went
>> through peer review), I think it makes more sense to build on these two
>> sections we already have.
>
> I still think the RFC process must contain its own “Decision Making”
> process and must not refer to external parts that could be changed
> without going via this RFC process.
>
> Somehow, from my point of view, it makes more sense to encode “Decision
> Making” or “Commit Access” or “Teams” via future RFCs than via sections
> in the manual.  And we need to bootstrap the “Decision Making”, no?

I agree that sections in the manual are suboptimal.  That is why I
proposed moving contributing.texi to a document of its own, which would
sit next to the RFC process document.  I don’t consider it a
prerequisite though.

> For sure, I agree that we do not build from nothing.  To me, this very
> first RFC makes explicit the structure we already have.  Maybe I
> misunderstand something, IMHO, we should avoid the temptation to say:
> Hey we already have a way to collaborate thus let implicitly rely on.
>
> Hum? 🤔 Somehow, I would find the RFC process incomplete without an
> explicit self-contained “Decision Making” section.

What I’d like to stress is that decision making also happens outside the
RFC process; not everything will go through the RFC process.  So we’ll
need to have that manual section for day-to-day contributions anyway.

But yeah, maybe we can have one specific to the RFC document, too.

Ludo’.

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

[Artyom V. Poptsov]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

Hello Noé Lopez,

thanks for pushing this idea forward!  I think that the RFC process will
help to track all the major initiatives in GNU Guix -- present and
future ones.

I know that there are several long-term big projects inside Guix, namely
Guile daemon, distributed substitutes and maybe more.  In my view the
problem is that the information about those projects is buried in the
Git branches and E-Mail discussions.  Maybe RFCs in the well-known place
inside the repository will help developers to see what the community at
large is up to.

> # Ludovic Courtès:
> # I’d go for one format, preferably Markdown because we have a library to
> # parse it.

To my taste, as for Emacs user, the plain old org-mode format is good
enough to write RFCs, but that's no more than a preference.  Many people
using Markdown nowadays so maybe it will help to make the RFC process
more friendly for newcomers.

- avp

-- 
Artyom "avp" Poptsov <poptsov.artyom@gmail.com>
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 869 bytes --]

[bug#74736] [PATCH v3] rfc: Add Request-For-Comment process.

[Simon Tournier]

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

Co-authored-by: Noé Lopez <noe@xn--no-cja.eu>
Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
---
 rfc/0000-template.txt    |  76 ++++++++++++
 rfc/0001-rfc-process.txt | 248 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 324 insertions(+)
 create mode 100644 rfc/0000-template.txt
 create mode 100644 rfc/0001-rfc-process.txt

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

[bug#74736] [PATCH v3] rfc: Add Request-For-Comment process.

[Ludovic Courtès]

Thanks for v3!

Some of my more superficial comments earlier this week remain
unaddressed:

  • I think it should be Markdown, and in a separate repo.

  • There are too many explicit references to Debbugs, which I think is
    not future-proof.

I think the text itself needs more work to address and remove remaining
comments that appear in the body, to improve grammar and wording, and to
make it shorter (it’s way too long IMO).  But that can come in a second
phase.

Questions/comments about the process that I overlooked before:

> +The lifetime of an RFC is structured into the following recommended periods:
> +
> +  submission (7d) ⟶ comments (30–60d) ⟶ last call (14d) ⟶ withdrawn OR final

This diagram doesn’t show everything I think; for example…

> +*** 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.

… what happens when the submitter doesn’t find supporters in that
period? I’m guessing the RFC goes in “withdrawn” state?

The diagram should reflect that, and we can render it with Dot.

> +*** 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.

I think committers here are mentioned as a simple way to express
membership and avoid infiltration, but it has the downside of ignoring
many members and giving committers a special privilege.

I propose this definition: anyone who is on a team (in ‘teams.scm’) is a
voting member*.

We can keep a quorum, but I think 50% of the voters is too ambitious;
maybe 25%?

This would become¹:

  Once the final version is published, team members have 14 days to cast
  one of the following votes about the RFC:

    - Support (+1);
    - Accept (0);
    - Reject (-2).

  Votes are cast by replying on the patch-tracking entry of the RFC.

  The RFC is accepted if (1) at least 25% of the voting members cast a
  vote, and (2) the sum of votes is non-negative.  In other cases, the
  RFC is withdrawn.

Thoughts?

Ludo’.


* We’ll have to create new teams and update them so we don’t forget
  anyone, notably translators, sysadmins, graphics designers, and so on.

¹ Inspired by
  <https://codeberg.org/mergiraf/mergiraf/src/branch/main/GOVERNANCE.md>.

[bug#74736] [PATCH v3] rfc: Add Request-For-Comment process.

[Noé Lopez via Guix-patches via]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> +** Timeline
> +
> +The lifetime of an RFC is structured into the following recommended periods:

What does recommended mean in this case?  Do you mean that someone can
skip any period they want or reduce the time if consesus is reached or
something else?

> +It moves to the last call period.
> +
> +*** Last call (up to 14 days)

There should be a lower limit.

> +
> +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.

I would add that a person with commit access that does not vote counts
as +1 or =0.  Though I doubt if a voting process like this is good for
consensus: if 5 people are for and 4 against it should not pass.

I like Ludo’s idea of using teams, but I fear that for some changes
people might not care enough to have even 25% of them vote.

[bug#74736] [PATCH v4 0/1] rfc: Add Request-For-Comment process.

[Noé Lopez via Guix-patches via]

From: Noé Lopez <noelopez@free.fr>

Hi,

Here is a fourth version, I have changed to Markdown format using Pandoc, and
fixed some typos.

I dropped the template for now to ease the process. We can bring it back once
there is consensus on the main document.

I tried making a Graphviz diagram but I’m not convinced:
digraph "RFC Lifetime" {
    submission[label=<Submission<br />7 days>]
    comments[label=<Comments<br />30–60 days>]
    last_call[label=<Last call<br />14 days>]
    withdrawn[label=Withdrawn, shape=rectangle]
    final[label=Final, shape=rectangle]
    
    submission -> comments
    comments -> last_call
    last_call -> withdrawn
    last_call -> final
    
    withdrawn -> submission [label="New version"]
    
    comments -> withdrawn
}

Good evening and holidays,
Noé

Simon Tournier (1):
  rfc: Add Request-For-Comment process.

 rfc/0001-rfc-process.md | 254 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 254 insertions(+)
 create mode 100644 rfc/0001-rfc-process.md


base-commit: 1affd2b5aa7f5467a44cf757c4fc0c6956d3f3c9
-- 
2.46.0

[bug#74736] [PATCH v4 1/1] rfc: Add Request-For-Comment process.

[Noé Lopez via Guix-patches via]

From: Simon Tournier <zimon.toutoune@gmail.com>

* rfc/0001-rfc-process.txt: New file.

Co-authored-by: Noé Lopez <noe@xn--no-cja.eu>
Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208
---
 rfc/0001-rfc-process.md | 254 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 254 insertions(+)
 create mode 100644 rfc/0001-rfc-process.md

diff --git a/rfc/0001-rfc-process.md b/rfc/0001-rfc-process.md
new file mode 100644
index 0000000000..7db420c824
--- /dev/null
+++ b/rfc/0001-rfc-process.md
@@ -0,0 +1,254 @@
+-   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 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.
+
+-   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 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. 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 access 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 status 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 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
-- 
2.46.0

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

[Ludovic Courtès]

Hi Noé,

Thanks for this new version.

Noé Lopez <noe@noé.eu> skribis:

> +### 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.

[...]

> +### 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 access 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 status quo continues.

It seems unchanged compared to v3.  WDYT of my comments, suggestions,
and proposed wording:

  https://issues.guix.gnu.org/74736#9

?

I think we should now make sure we reach consensus on the timeline, and
in particular:

  1. on the voting process;

  2. on the submission -> withdrawn transition, in case nobody supports
     the RFC.

Once we have that, we can fine-tune the language and hopefully be done
within a couple of weeks.

I like the Dot graph you submitted!  Here’s an updated version, with a
new submission -> withdrawn arrow (as proposed in the comment above) and
with hopefully clearer names (in particular “Voting Period” rather than
“Last call”):

--8<---------------cut here---------------start------------->8---
digraph "RFC Timeline" {
    submission[label=<Submission Period<br />7 days>]
    comments[label=<Discussion Period<br />30–60 days>]
    last_call[label=<Voting 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
}
--8<---------------cut here---------------end--------------->8---

Thoughts?

Thanks for getting the ball rolling!

Ludo’.

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

[Simon Tournier]

Hi,

On Mon, 23 Dec 2024 at 15:42, Ludovic Courtès <ludo@gnu.org> wrote:

>> +### 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 access 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 status quo continues.
>
> It seems unchanged compared to v3.  WDYT of my comments, suggestions,
> and proposed wording:
>
>   https://issues.guix.gnu.org/74736#9
>
> ?

Quoting:

        > I think committers here are mentioned as a simple way to express
        > membership and avoid infiltration, but it has the downside of ignoring
        > many members and giving committers a special privilege.

It’s not about infiltration, it’s about to be sure that people agree and
do not overlook.

        > I propose this definition: anyone who is on a team (in ‘teams.scm’) is a
        > voting member*.

I agree.

        > We can keep a quorum, but I think 50% of the voters is too ambitious;
        > maybe 25%?

Well, I picked 50% almost randomly. ;-)  Somehow, I do not have a strong
opinion.  My concern is only to be sure that we have a consensus and not
something falling between the cracks.

        > This would become¹:
        >
        >   Once the final version is published, team members have 14 days to cast
        >   one of the following votes about the RFC:
        >
        >     - Support (+1);
        >     - Accept (0);
        >     - Reject (-2).
        >
        >   Votes are cast by replying on the patch-tracking entry of the RFC.
        >
        >   The RFC is accepted if (1) at least 25% of the voting members cast a
        >   vote, and (2) the sum of votes is non-negative.  In other cases, the
        >   RFC is withdrawn.

For me, if we have only one minus, it means we do not have consensus.
Therefore, the person who cannot live with the proposal must be
proactive in finding a solution that we all agree on.

In other words, the numbers are not for being summed, the aim is to
capture:

 - Support
 - I can with with it
 - I cannot live with it

BTW, I do not like the word “Reject” and I prefer “Disagree” or even
better “I cannot live with it”.


> I think we should now make sure we reach consensus on the timeline, and
> in particular:
>
>   1. on the voting process;

Maybe I misunderstand something.  From my point, we do not “vote”
because we are trying to work using consensus.  When I proposed +1/0/-1
my aim was not to “vote“ but to be sure that the proposal is not
overlooked.

Therefore, instead of “Voting Period”, I would prefer “Replying Period”
or something like that.

WDYT?

Cheers,
simon

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

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

>>> +### 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 access 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 status quo continues.
>>
>> It seems unchanged compared to v3.  WDYT of my comments, suggestions,
>> and proposed wording:
>>
>>   https://issues.guix.gnu.org/74736#9
>>
>> ?
>
> Quoting:
>
>         > I think committers here are mentioned as a simple way to express
>         > membership and avoid infiltration, but it has the downside of ignoring
>         > many members and giving committers a special privilege.
>
> It’s not about infiltration, it’s about to be sure that people agree and
> do not overlook.

Right.  (Though I think infiltration is also a valid concern.)

>         > I propose this definition: anyone who is on a team (in ‘teams.scm’) is a
>         > voting member*.
>
> I agree.
>
>         > We can keep a quorum, but I think 50% of the voters is too ambitious;
>         > maybe 25%?
>
> Well, I picked 50% almost randomly. ;-)  Somehow, I do not have a strong
> opinion.  My concern is only to be sure that we have a consensus and not
> something falling between the cracks.

Yes, agreed.

>         > This would become¹:
>         >
>         >   Once the final version is published, team members have 14 days to cast
>         >   one of the following votes about the RFC:
>         >
>         >     - Support (+1);
>         >     - Accept (0);
>         >     - Reject (-2).
>         >
>         >   Votes are cast by replying on the patch-tracking entry of the RFC.
>         >
>         >   The RFC is accepted if (1) at least 25% of the voting members cast a
>         >   vote, and (2) the sum of votes is non-negative.  In other cases, the
>         >   RFC is withdrawn.
>
> For me, if we have only one minus, it means we do not have consensus.
> Therefore, the person who cannot live with the proposal must be
> proactive in finding a solution that we all agree on.

Yes.

> In other words, the numbers are not for being summed, the aim is to
> capture:
>
>  - Support
>  - I can with with it
>  - I cannot live with it
>
> BTW, I do not like the word “Reject” and I prefer “Disagree” or even
> better “I cannot live with it”.

I like the spirit of it, and I would propose exactly that if people were
to meet physically at a meeting.

The problem I see here is that we’re online, all communication is
asynchronous, sometimes concise, sometimes verbose, sometimes frequent,
sometimes rare, participants may be friends or strangers, and yet we
need to come to a clear shared understanding of whether the RFC is
“accepted” or “withdrawn”.

If we keep it too fuzzy, I fear we might be unable to decide what to do.

>> I think we should now make sure we reach consensus on the timeline, and
>> in particular:
>>
>>   1. on the voting process;
>
> Maybe I misunderstand something.  From my point, we do not “vote”
> because we are trying to work using consensus.  When I proposed +1/0/-1
> my aim was not to “vote“ but to be sure that the proposal is not
> overlooked.

I’m all for consensus-based decision making, as you know.  My concern is
making sure a clear and unambiguous decision is made at the end of the
RFC period.

The risk I see is that of the final withdrawn/accepted decision to be
perceived as an arbitrary choice by the people in power (RFC editors,
long-timers, etc.), or that of being unable to make that final decision.
It’s a risk that perhaps exists only in the most contentious cases, but
if we can use vote as a tool to avoid it, it’s worth considering.

WDYT?

Ludo’.

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

[Simon Tournier]

Hi Ludo,

On Thu, 26 Dec 2024 at 12:28, Ludovic Courtès <ludo@gnu.org> wrote:

>> In other words, the numbers are not for being summed, the aim is to
>> capture:
>>
>>  - Support
>>  - I can with with it
>>  - I cannot live with it
>>
>> BTW, I do not like the word “Reject” and I prefer “Disagree” or even
>> better “I cannot live with it”.
>
> I like the spirit of it, and I would propose exactly that if people were
> to meet physically at a meeting.
>
> The problem I see here is that we’re online, all communication is
> asynchronous, sometimes concise, sometimes verbose, sometimes frequent,
> sometimes rare, participants may be friends or strangers, and yet we
> need to come to a clear shared understanding of whether the RFC is
> “accepted” or “withdrawn”.
>
> If we keep it too fuzzy, I fear we might be unable to decide what to do.
>
>>> I think we should now make sure we reach consensus on the timeline, and
>>> in particular:
>>>
>>>   1. on the voting process;
>>
>> Maybe I misunderstand something.  From my point, we do not “vote”
>> because we are trying to work using consensus.  When I proposed +1/0/-1
>> my aim was not to “vote“ but to be sure that the proposal is not
>> overlooked.
>
> I’m all for consensus-based decision making, as you know.  My concern is
> making sure a clear and unambiguous decision is made at the end of the
> RFC period.
>
> The risk I see is that of the final withdrawn/accepted decision to be
> perceived as an arbitrary choice by the people in power (RFC editors,
> long-timers, etc.), or that of being unable to make that final decision.
> It’s a risk that perhaps exists only in the most contentious cases, but
> if we can use vote as a tool to avoid it, it’s worth considering.

As you wrote in [1], I think we have the same concern but we have a
different idea behind the same “voting” word.  Instead I agree, it’s a
deliberation period to be sure that the consensus reaches the quorum
(e.g., 25% of the all team members).

Somehow, +1/0/-1 seems another way to express the exact same idea for
the approval statuses (e.g., see Wayland [2]):

    + ACK, or “acknowledged”,
          meaning that the member supports in principle
    + NOPP, or “no opposition”,
          meaning that the member is not opposed in principle
    + NACK, or “negative acknowledgement”
          meaning that the member is opposed in principle.

which reads:

    - Support                +1  ACK   Awesome!
    - I can with with it      0  NOPP  LGTM
    - I cannot live with it  -1  NACK  WDYT about…


The last column is how we are collaborating over all the mailing lists
since years. 


Again, if someone wants to “block“ the RFC, then the blocker must be
active in proposing an alternative and/or explain with details why the
status quo is preferable.

In the other words, I disagree to add numbers: how many ’Support’ against
‘I cannot live with it’?  1 ’Support’ vs 2 ’I cannot live with it’?  Why
not 1 vs 3?  Or more?  Or less?

However, I agree that consensus might scale poorly and might outcome
some blocked situations.  That’s why ‘Decision making: consensus’ must
be included in the process itself and carefully worded. :-)  For these
potential blocked situations, the last word is about maintainers.


Well, a “positive consensus is reached” if after the “Deliberation
Period“, we have 25% of all the members of all the teams expressing
either ’Support’ or either ’I can live with it’.  If after this period,
we have only one ’I cannot live with it’, then the RFC is ’dismissed’.

Please note that ’I cannot live with it’ implies an active friendly
discussion before the end of the “Deliberation Period”.  In other words,
I cannot sleep and the day before the “Deliberation Period” just raise:
Hey, no ’I cannot live with it’.

WDYT?

Well, I will try to clarify the proposal in the coming days in order to
remove the “too fuzzy” (being active, being blocker, etc.)

Cheers,
simon


1: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Ludovic Courtès <ludo@gnu.org>
Mon, 30 Dec 2024 12:03:29 +0100
id:87seq5tou6.fsf_-_@gnu.org
https://issues.guix.gnu.org/74736
https://issues.guix.gnu.org/msgid/87seq5tou6.fsf_-_@gnu.org
https://yhetil.org/guix/87seq5tou6.fsf_-_@gnu.org

2:
https://chromium.googlesource.com/external/anongit.freedesktop.org/git/wayland/wayland-protocols/+/HEAD/GOVERNANCE.md

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

[Noé Lopez via Guix-patches via]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Noé,
>
> Thanks for this new version.
>
> Noé Lopez <noe@noé.eu> skribis:
>
>> +### 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.
>
> [...]
>
>> +### 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 access 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 status quo continues.
>
> It seems unchanged compared to v3.  WDYT of my comments, suggestions,
> and proposed wording:
>
>   https://issues.guix.gnu.org/74736#9
>
> ?

As Simon said, I think a vote goes against the principle of
consensus. Maybe we can take inspiration from the wayland protocol?

If a stakeholder thinks the RFC is complete and satisfactory, they ACK
it.  If the RFC needs changes, they simply comment and if they are
against it they NACK it.

Quoting Mike Blumenkrantz:
>A NACK for an experimental protocol carries some variation on the following meanings:
>This idea is broken and cannot work.
>OR
>This approach is fundamentally against the core principles or spirit of Wayland.
>A NACK must be well-justified, as determined by members of the
>governance team, who are assumed to be acting in good faith for the best interests of the project.

In this way, we can say that an RFC needs a specific amount of ACKs and
no NACKs to be merged, ensuring everybody is at least fine with it and
the stakeholders are interested enough to ACK it.

>
> I think we should now make sure we reach consensus on the timeline, and
> in particular:
>
>   1. on the voting process;
>
>   2. on the submission -> withdrawn transition, in case nobody supports
>      the RFC.
>
> Once we have that, we can fine-tune the language and hopefully be done
> within a couple of weeks.
>
> I like the Dot graph you submitted!  Here’s an updated version, with a
> new submission -> withdrawn arrow (as proposed in the comment above) and
> with hopefully clearer names (in particular “Voting Period” rather than
> “Last call”):
>
> --8<---------------cut here---------------start------------->8---
> digraph "RFC Timeline" {
>     submission[label=<Submission Period<br />7 days>]
>     comments[label=<Discussion Period<br />30–60 days>]
>     last_call[label=<Voting 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
> }
> --8<---------------cut here---------------end--------------->8---
>
> Thoughts?

I agree with that timeline, but I would have just “forgotten” an RFC
that doesn’t pass the submission period, since that would mean it is not
good enough to be discussed.  It can just be kept in the mail archives
like any other unfinished idea.

A withdrawn RFC would mean keeping it in the rfc/withdrawn directory.

This was also why I had proposed the idea of keeping a set of available
co-supporters, since any well written RFC should be able to get past the
submission period even if you can’t find someone to co-support.

Good evening,
Noé

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

[Ludovic Courtès]

Hi Noé,

Noé Lopez <noe@noé.eu> skribis:

>> It seems unchanged compared to v3.  WDYT of my comments, suggestions,
.> and proposed wording:
>>
>>   https://issues.guix.gnu.org/74736#9
>>
>> ?
>
> As Simon said, I think a vote goes against the principle of
> consensus.

OK.  As I wrote in my reply to Simon, my thought here was that “voting”*
would give a clear and unambiguous way, not subject to interpretation,
to decide whether the RFC is withdrawn: it’s easier to add numbers than
to determine whether “a positive consensus is reached” (current
wording).

But I don’t know, I guess that’s an “I will live with it” from me on
this one.  :-)

Two other issue I raised was the quorum: Simon proposed half of the
committers; I propose 25% of team members.  Thoughts?

* Maybe “voting” is misleading; “deliberation” might be clearer.

>>   2. on the submission -> withdrawn transition, in case nobody supports
>>      the RFC.

[...]

> I agree with that timeline, but I would have just “forgotten” an RFC
> that doesn’t pass the submission period, since that would mean it is not
> good enough to be discussed.  It can just be kept in the mail archives
> like any other unfinished idea.
>
> A withdrawn RFC would mean keeping it in the rfc/withdrawn directory.

Oh right, forgotten/dismissed seems more appropriate than withdrawn
here.

Anyway, I think we should aim for finalization of v1 of the RFC process
by, say, Jan. 15th.  I will dedicate some time to tweak the wording, and
then we can call it a thing.

(A bit sad that it’s just the three of us talking, we wouldn’t have the
quorum here…)

Ludo’.

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

[Noé Lopez via Guix-patches via]

Ludovic Courtès <ludo@gnu.org> writes:

> OK.  As I wrote in my reply to Simon, my thought here was that “voting”*
> would give a clear and unambiguous way, not subject to interpretation,
> to decide whether the RFC is withdrawn: it’s easier to add numbers than
> to determine whether “a positive consensus is reached” (current
> wording).
>

This is why an ACK/NACK system works great in my opinion: you send “ACK”
or “NACK” litteraly so your opinion is clear.  And you can just count
the number of each, without implying a vote.

> But I don’t know, I guess that’s an “I will live with it” from me on
> this one.  :-)
>
> Two other issue I raised was the quorum: Simon proposed half of the
> committers; I propose 25% of team members.  Thoughts?
>

I don’t have the experience to judge, but I would just do “as long as no
one is against it its good”.

The reason is that I’m afraid that people might just not participate
because they are fine with an RFC or don’t care, and so it would just
get stuck there.

If you look at this RFC, we are four participants, how many will we get
after the finalization?

Half of the committers is 25 people (based on .guix-authorizations), and
a quarter of the team members is 10.  Personnally, I have trouble
imagining that this amount of people will come to send a mail to the
RFC.

> * Maybe “voting” is misleading; “deliberation” might be clearer.
>
>>>   2. on the submission -> withdrawn transition, in case nobody supports
>>>      the RFC.
>
> [...]
>
>> I agree with that timeline, but I would have just “forgotten” an RFC
>> that doesn’t pass the submission period, since that would mean it is not
>> good enough to be discussed.  It can just be kept in the mail archives
>> like any other unfinished idea.
>>
>> A withdrawn RFC would mean keeping it in the rfc/withdrawn directory.
>
> Oh right, forgotten/dismissed seems more appropriate than withdrawn
> here.
>
> Anyway, I think we should aim for finalization of v1 of the RFC process
> by, say, Jan. 15th.  I will dedicate some time to tweak the wording, and
> then we can call it a thing.
>

Good idea!  I’ll be waiting for your v5 then.  And then I can bring
back the RFC template.

> (A bit sad that it’s just the three of us talking, we wouldn’t have the
> quorum here…)
>

Agreed.

Lastly, do we want to move the RFCs to a separate git repository?

Have a nice day,
Noé

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

[Ludovic Courtès]

Noé Lopez <noe@noé.eu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> OK.  As I wrote in my reply to Simon, my thought here was that “voting”*
>> would give a clear and unambiguous way, not subject to interpretation,
>> to decide whether the RFC is withdrawn: it’s easier to add numbers than
>> to determine whether “a positive consensus is reached” (current
>> wording).
>>
>
> This is why an ACK/NACK system works great in my opinion: you send “ACK”
> or “NACK” litteraly so your opinion is clear.  And you can just count
> the number of each, without implying a vote.

OK, got it, we agree on this.

>> But I don’t know, I guess that’s an “I will live with it” from me on
>> this one.  :-)
>>
>> Two other issue I raised was the quorum: Simon proposed half of the
>> committers; I propose 25% of team members.  Thoughts?

[...]

> Half of the committers is 25 people (based on .guix-authorizations), and
> a quarter of the team members is 10.  Personnally, I have trouble
> imagining that this amount of people will come to send a mail to the
> RFC.

So are you saying you’d want no quorum at all?  (Your revision still
reads “50% committers”.)

>> Anyway, I think we should aim for finalization of v1 of the RFC process
>> by, say, Jan. 15th.  I will dedicate some time to tweak the wording, and
>> then we can call it a thing.
>>
>
> Good idea!  I’ll be waiting for your v5 then.  And then I can bring
> back the RFC template.

OK, will do in the coming days.

>> (A bit sad that it’s just the three of us talking, we wouldn’t have the
>> quorum here…)
>>
>
> Agreed.
>
> Lastly, do we want to move the RFCs to a separate git repository?

I think so.  I’ll ask for it on Savannah.

Thanks,
Ludo’.

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

[Noé Lopez via Guix-patches via]

>> Half of the committers is 25 people (based on .guix-authorizations), and
>> a quarter of the team members is 10.  Personnally, I have trouble
>> imagining that this amount of people will come to send a mail to the
>> RFC.
>
> So are you saying you’d want no quorum at all?  (Your revision still
> reads “50% committers”.)

To take a realistic example, say I make an RFC for P2P substitute
distribution with GNUNet/ERIS, this is a big change that requires an RFC
but I have trouble imagining that ten people in the team members are
interested in that.

Teams are specialized after all, if I add myself to the games team it
doesn’t mean I care about RFCs for what would be the core team.

That said I trust your experience to find a quorum that works and if you
think ten is realistic then go for it.

>> Lastly, do we want to move the RFCs to a separate git repository?
>
> I think so.  I’ll ask for it on Savannah.
>

Great!

Have a nice day,
Noé

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

[Simon Tournier]

Hi Noé,

On Sun, 05 Jan 2025 at 13:51, Noé Lopez via Guix-patches via <guix-patches@gnu.org> wrote:

> To take a realistic example, say I make an RFC for P2P substitute
> distribution with GNUNet/ERIS, this is a big change that requires an RFC
> but I have trouble imagining that ten people in the team members are
> interested in that.
>
> Teams are specialized after all, if I add myself to the games team it
> doesn’t mean I care about RFCs for what would be the core team.

Well, considering this example, I remember a session at Guix Days last
year (or last last year?) when pukkamustard explained ERIS.  If I
remember correctly, we were more than 10 people and after the
explanations and questions/answers, we had an informed opinion; I mean I
guess most attendees were able to express either Support, Accept or
Disagree.

For sure, the number of people able to tackle all the implementation
details is probably lower than 10.  However, I am confident that more
than 10 team members are skilled enough to build a consensus on any
topic*.

Today, merging a patch is done using “Lazy Consensus“: it assumes
general consent if no responses are posted within a defined period (15
days).

For “significant changes”, we are looking for a “Consensus Approval”.

Therefore, we need a way to define this “Consensus Approval”.  That’s
what it’s named “Deliberation Period”: after a “Comment Period” where we
all try to forge an informed opinion (if we are not an expert on the
topic at hand), then we express what we judge the best for the project.

That’s said, maybe 25% is too much?  What does it appear to you better?

Cheers,
simon

PS: About “Lazy Consensus” and “Consensus Approval”, see Apache [1]. :-)

*build consensus on any topic: FWIW, I have seen random citizens without
apriori knowledge took complex decisions in Court about crime.


1: https://community.apache.org/committers/decisionMaking.html

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

[Ludovic Courtès]

Hi,

Noé Lopez <noe@noé.eu> skribis:

> To take a realistic example, say I make an RFC for P2P substitute
> distribution with GNUNet/ERIS, this is a big change that requires an RFC
> but I have trouble imagining that ten people in the team members are
> interested in that.
>
> Teams are specialized after all, if I add myself to the games team it
> doesn’t mean I care about RFCs for what would be the core team.

Yes.

I’m not sure about this particular example though: *if* this is
implemented as an opt-in functionality, it’s not necessarily a “big
change” in that (1) it’s disabled by default, and (2) it could be
removed entirely from the code base anytime.  So under these conditions,
it would not even qualify for the RFC process.

Conversely, the examples given in the current RFC draft really have an
impact on everyone and are hard or impossible to revert.

> That said I trust your experience to find a quorum that works and if you
> think ten is realistic then go for it.

I don’t have experience but I think that we want to make sure there’s
enough community input.  This will require publicity about each RFC and
probably we’ll have to do some web/automation work to help publicize new
RFCs and RFC status changes.

Fundamentally, we need to view ourselves as a community with shared
goals, making decisions together—that is what it means to be a “member”
of the project.

Ludo’.

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

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

>> Lastly, do we want to move the RFCs to a separate git repository?
>
> I think so.  I’ll ask for it on Savannah.

I filed a support request to create it:

  https://savannah.nongnu.org/support/?111169

Ludo’.

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

[Ludovic Courtès]

Repository created!

  https://git.savannah.gnu.org/cgit/guix/requests-for-comments.git/

Ludo’.

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

[Simon Tournier]

Hi Ludo,

On Thu, 09 Jan 2025 at 14:27, Ludovic Courtès <ludo@gnu.org> wrote:
> Repository created!
>
>   https://git.savannah.gnu.org/cgit/guix/requests-for-comments.git/

I like the idea of ’Guix Common Document’ (GCD) instead of
Request-For-Comment (RFC).  Do you think it would be possible to rename
this repository before it we start to effectively it?

Cheers,
simon

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

[Noé Lopez via Guix-patches via]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Ludo,
>
> On Thu, 09 Jan 2025 at 14:27, Ludovic Courtès <ludo@gnu.org> wrote:
>> Repository created!
>>
>>   https://git.savannah.gnu.org/cgit/guix/requests-for-comments.git/
>
> I like the idea of ’Guix Common Document’ (GCD) instead of
> Request-For-Comment (RFC).  Do you think it would be possible to rename
> this repository before it we start to effectively it?
>
> Cheers,
> simon

Hi Simon,

Can you explain the reasoning for that name?  I don’t think I understand
what it means.

Thanks,
Noé

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

[Simon Tournier]

Hi Noé,

On Fri, 10 Jan 2025 at 11:39, Noé Lopez via Guix-patches via <guix-patches@gnu.org> wrote:

> Can you explain the reasoning for that name?  I don’t think I understand
> what it means.

Personally, I find ’Guix Common Document’ more self-explanatory than
Request-for-Comments.  Because once the proposal is accepted or
withdrawn there is no more request nor comment. ;-)

Well, I know RFC is the usual name for this kind of thing (I also used
RFC when discussing it).  Nonetheless, I find nicer to not follow such
“convention”, as for example Python Enhancement Proposals (PEP)
does. :-) And the term RFC is already too much overloaded in Guix
mailing list, IMHO.

In addition, I like ’Guix Common Document’ because it expresses what it
is: our shared (common) direction.  Moreover it echoes with Commons and
somehow the process tries to capture that: what we collectively want to
preserve.  Last, pun with mathematical notion of greatest common divisor
(gcd) [1].

Does it make sense?

Cheers,
simon



1: https://en.wikipedia.org/wiki/Greatest_common_divisor

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

[Noé Lopez via Guix-patches via]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Noé,
>
> On Fri, 10 Jan 2025 at 11:39, Noé Lopez via Guix-patches via <guix-patches@gnu.org> wrote:
>
>> Can you explain the reasoning for that name?  I don’t think I understand
>> what it means.
>
> Personally, I find ’Guix Common Document’ more self-explanatory than
> Request-for-Comments.  Because once the proposal is accepted or
> withdrawn there is no more request nor comment. ;-)
>
> Well, I know RFC is the usual name for this kind of thing (I also used
> RFC when discussing it).  Nonetheless, I find nicer to not follow such
> “convention”, as for example Python Enhancement Proposals (PEP)
> does. :-) And the term RFC is already too much overloaded in Guix
> mailing list, IMHO.
>
> In addition, I like ’Guix Common Document’ because it expresses what it
> is: our shared (common) direction.  Moreover it echoes with Commons and
> somehow the process tries to capture that: what we collectively want to
> preserve.  Last, pun with mathematical notion of greatest common divisor
> (gcd) [1].
>
> Does it make sense?

Makes sense, we could add the explanation to the readme :)

Thanks,
Noé

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

[Suhail Singh]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Well, I know RFC is the usual name for this kind of thing (I also used
> RFC when discussing it).  Nonetheless, I find nicer to not follow such
> “convention”, as for example Python Enhancement Proposals (PEP)
> does. :-) And the term RFC is already too much overloaded in Guix
> mailing list, IMHO.
>
> In addition, I like ’Guix Common Document’ because it expresses what
> it is: our shared (common) direction.  Moreover it echoes with Commons
> and somehow the process tries to capture that: what we collectively
> want to preserve.  Last, pun with mathematical notion of greatest
> common divisor (gcd) [1].

To the extent it is important that the term be somewhat
self-explanatory, to me the term "Guix Common Document" did not imply
that it is a "proposal", nor that it is intended to "change" or
"enhance" current implementation in some specific way(s).  As with all
anecdotal evidence, take this with a grain of salt.

IMO, "Guix Change Process", or "Guix Change Proposal", or "Guix
Enhancement Proposal" may be more self-evident.

-- 
Suhail

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

[Simon Tournier]

Hi,

On Fri, 10 Jan 2025 at 19:47, Suhail Singh <suhailsingh247@gmail.com> wrote:

> IMO, "Guix Change Process", or "Guix Change Proposal", or "Guix
> Enhancement Proposal" may be more self-evident.

There is only two things really hard: cache invalidation and naming. ;-)

Thank you for these suggestions.

Cheers,
simon

[bug#74736] [PATCH v5] rfc: Add Request-For-Comment process.

[Simon Tournier]

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

Co-authored-by: Noé Lopez <noe@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@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.  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

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Hello,

As proposed before, here’s a reworked version based on v5.  The intent
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:

  • Instead of “supporter” and “co-supporter”, I propose “author(s)” and
    “supporter(s)” (there must be at least one supporter).

  • Explicitly state the license of RFCs (CC-BY-SA or GFDL).

  • Clarify that the deliberation period lasts exactly 14 days (was “up
    to 14 days” in one place, “14 days” in another).

  • Consistently name the different periods.

  • Remove mention of the ‘withdrawn/’ directory: it’s redundant with
    the ‘status’ header.

  • Clarify what to do with “deprecated” RFCs.

  • Clarify headers of this RFC.

  • Clarify that this is not just for technical changes.
  
I can proofread and possibly propose minor tweaks the template
afterwards.

Thoughts?

Ludo’.


[-- Attachment #2: rfc-v6.md --]
[-- Type: text/plain, Size: 9427 bytes --]

title: Requests-for-Comment Process
id: 000
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
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
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 “significant” changes, which 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 “Contributing” 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’s 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’s
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=<Submission Period<br />up to 7 days>]
    comments[label=<Discussion Period<br />30–60 days>]
    deliberation[label=<Deliberation Period<br />14 days>]
    withdrawn[label=Withdrawn, shape=rectangle]
    final[label=Final, shape=rectangle]
    
    submission -> comments
    submission -> withdrawn
    comments -> deliberation
    deliberation -> withdrawn
    deliberation -> final
    
    withdrawn -> submission [label="New version"]
    
    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:

- “I support”, meaning that one supports the proposal);
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation 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 “Decision Making”
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 than
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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Noé Lopez via Guix-patches via]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> As proposed before, here’s a reworked version based on v5.  The intent
> 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:
>
>   • Instead of “supporter” and “co-supporter”, I propose “author(s)” and
>     “supporter(s)” (there must be at least one supporter).
>
>   • Explicitly state the license of RFCs (CC-BY-SA or GFDL).
>
>   • Clarify that the deliberation period lasts exactly 14 days (was “up
>     to 14 days” in one place, “14 days” in another).
>
>   • Consistently name the different periods.
>
>   • Remove mention of the ‘withdrawn/’ directory: it’s redundant with
>     the ‘status’ header.
>
>   • Clarify what to do with “deprecated” RFCs.
>
>   • Clarify headers of this RFC.
>
>   • Clarify that this is not just for technical changes.
>   
> I can proofread and possibly propose minor tweaks the template
> afterwards.
>
> Thoughts?
>
> Ludo’.

This is great, thanks!  A few comments below:

>
> title: Requests-for-Comment Process
> id: 000

001, since the template takes id 0000 for ease of access.

> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> supporters: ?
> submitted: 2024-12-12
> date: 2025-01-15

It’s a good place to add:
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only

> ---
>
> # 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
> “significant” enough to require attention from the community 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 “significant” 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 `<package>` 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.)

Missing a dot at the end of the sentence.

> # Detailed Design
>
> ## When to Follow This Process
>
> The RFC process applies only to “significant” changes, which 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 “Contributing” chapter.
>
> ## How the Process Works
>
> 1. Clone https://git.savannah.gnu.org/git/guix/requests-for-comments.git .

Why the alone dot?

> 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’s 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).
>

So we are now three authors and no supporters for this RFC?  Could we
say that more than one author also works for submitting?

> ## Supporters
>
> A supporter is a contributor sufficiently familiar with the project’s
> 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=<Submission Period<br />up to 7 days>]
>     comments[label=<Discussion Period<br />30–60 days>]
>     deliberation[label=<Deliberation Period<br />14 days>]
>     withdrawn[label=Withdrawn, shape=rectangle]
>     final[label=Final, shape=rectangle]
>     
>     submission -> comments
>     submission -> withdrawn
>     comments -> deliberation
>     deliberation -> withdrawn
>     deliberation -> final
>     
>     withdrawn -> submission [label="New version"]
>     
>     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:
>
> - “I support”, meaning that one supports the proposal);

This parenthesis is alone.

> - “I accept”, meaning that one consents to the implementation of the
>   proposal;
> - “I disapprove”, meaning that one opposes the implementation 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 “Decision Making”
> 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 .

Another alone dot 🤔

>
> ## 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).

I would add “or (at your option) any later version.”

>
> ## RFC Template
>
> The expected structure of RFCs is captured by the template in the file
> `0000-template.md`, written in English with Markdown ornaments.

Ornament is a complicated word, I would replace it with “syntax”.

>
> ## 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 than
> 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’t want the process to become unduly
> burdensome.  This is a careful balance which will require care to
> maintain moving forward.

Thanks for the v6, apart from my comments I think its great and ready to
be submitted :)

In my opinion there are too many unnecessary emphasis (mostly with `),
but I will live with it.

Have a nice day,
Noé

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

[Suhail Singh]

Noé Lopez <noe@noé.eu> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
> ...
>> id: 000
>
> 001, since the template takes id 0000 for ease of access.

Agreed.

>> supporters: ?

I'd like to be a supporter.  I suppose the authors get to determine
whether I am "sufficiently familiar", or is it based on self-reporting?
Perhaps this point should be clarified.

>> submitted: 2024-12-12
>> date: 2025-01-15

Should other dates such as target discussion period end as well as
target deliberation period end also be noted here?

> It’s a good place to add:
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only

Agreed.

>> A change may be deemed “significant” 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:

Stating these properties is helpful.

>> ## When to Follow This Process

Perhaps a "vs not" or equivalent could be added to the heading?

>> Most day-to-day contributions do *not* require an RFC; examples include:

I am glad that non-examples were also noted.

>> 1. Clone https://git.savannah.gnu.org/git/guix/requests-for-comments.git .
>
> Why the alone dot?

I imagine so as not to be mistaken as being part of the URL.  If so, I
would recommend we use < ... > delimiters here and elsewhere.  E.g.,

>> 1. Clone <https://git.savannah.gnu.org/git/guix/requests-for-comments.git>.

> So we are now three authors and no supporters for this RFC?  Could we
> say that more than one author also works for submitting?

I think a clarification on this point is needed.  As well, when there
are multiple authors if one or more of them could also act as
supporters.

>> Supporters help the author(s) by participating in discussions, amending
>> the document as it is being discussed, and acting as timekeepers.

The "amending the document" responsibility blurs the distinction between
authors and supporters.  Could that be replaced with "providing
constructive comments"?  E.g., this message of mine.

>> 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*.

At that point someone (or some bot) performing cleanup tasks is welcome
to close the issue, if not already closed?

>> https://www.seedsforchange.org.uk/consensus .
>
> Another alone dot 🤔

I propose "<...>." as noted above.

>> 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).
>
> I would add “or (at your option) any later version.”

Agreed.

>> The expected structure of RFCs is captured by the template in the file
>> `0000-template.md`, written in English with Markdown ornaments.
>
> Ornament is a complicated word, I would replace it with “syntax”.

Agreed.

>> ## Cost of Reverting
>>
>> The RFC process described in this documented can be amended by
                                     ^^^^^^^^^^
>> subsequent RFCs.

I propose:

#+begin_quote
  The RFC process described in this document can be amended and must be
  by via a subsequent RFC.
#+end_quote

-- 
Suhail

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

[Simon Tournier]

Hi,

On Wed, 08 Jan 2025 at 10:12, Suhail Singh <suhailsingh247@gmail.com> wrote:

> I'd like to be a supporter.  I suppose the authors get to determine
> whether I am "sufficiently familiar", or is it based on self-reporting?
> Perhaps this point should be clarified.

Thanks for your comment.  Indeed, let clarify it for the next version.

>>> submitted: 2024-12-12
>>> date: 2025-01-15
>
> Should other dates such as target discussion period end as well as
> target deliberation period end also be noted here?

I agree this needs a clarification.


Cheers,
simon

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[reza via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Thanks for pushing this forward.

As a maybe tangential comment: There is no mention of an identifier for an RFC (e.g. PEP number) or a unique string to identify or reference it?


On January 6, 2025 11:29:21 PM GMT+01:00, "Ludovic Courtès" <ludo@gnu.org> wrote:

Hello,

As proposed before, here’s a reworked version based on v5.  The intent
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:

  • Instead of “supporter” and “co-supporter”, I propose “author(s)” and
    “supporter(s)” (there must be at least one supporter).

  • Explicitly state the license of RFCs (CC-BY-SA or GFDL).

  • Clarify that the deliberation period lasts exactly 14 days (was “up
    to 14 days” in one place, “14 days” in another).

  • Consistently name the different periods.

  • Remove mention of the ‘withdrawn/’ directory: it’s redundant with
    the ‘status’ header.

  • Clarify what to do with “deprecated” RFCs.

  • Clarify headers of this RFC.

  • Clarify that this is not just for technical changes.
  
I can proofread and possibly propose minor tweaks the template
afterwards.

Thoughts?

Ludo’.


-- Sent from /e/OS Mail.

[-- Attachment #2: Type: text/html, Size: 1868 bytes --]

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi,

On Wed, 08 Jan 2025 at 06:33, reza via Guix-patches via <guix-patches@gnu.org> wrote:

> As a maybe tangential comment: There is no mention of an identifier
> for an RFC (e.g. PEP number) or a unique string to identify or
> reference it?

I think there is one: the first one is 001 and then they will be
incremented.  For instance, assuming v6, it would be: RFC 001, or RFC
001-rfc-process.

Is it clearer?

Cheers,
simon

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[reza via Guix-patches via]

Hi Simon

> I think there is one: the first one is 001 and then they will be
> incremented.  For instance, assuming v6, it would be: RFC 001, or RFC
> 001-rfc-process.

Thanks for clarification, I don't see this mention in the document? Also
will this mean we only can do 999 RFC's?

Best,
Reza

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi Reza,

On Fri, 17 Jan 2025 at 12:15, reza via Guix-patches via <guix-patches@gnu.org> wrote:

>                           I don't see this mention in the document?

Well, I think it’s covered with the term “sequence number” and with the
information provided by the 000-template.md.

    id: <the next available number>

>                                                                     Also
> will this mean we only can do 999 RFC's?

Well, this document will be amended a couple of times before we are
close to have 999 GCDs, I guess. :-) Therefore, we will refine depending
on how it goes.

Moreover, considering the changes that would have required such process
from the 10+ past years, I think we have some time for preparing the
case of 999 before we reach it. :-)

Cheers,
simon

PS: Fun: “sequence number” could be a Fibonacci sequence number… Even,
    it could be let to the author as an exercise to determine which
    “sequence” the project is following. ;-)

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

[pukkamustard]

Thank you all for working on this.

Some comments:

- I had to think if I am a _team member_ or not. The term is not defined in the
  document. I think this is mostly due to there not being a RFC on teams (yet).
  Still, to make the Process RFC understandable, I'd add a brief explanation of
  what team members are (i.e. members in etc/teams.scm). 
  
  Likewise, I think the Process RFC would be simpler to understand if feedback
  is required from a fixed number of team members instead of a percentage. I
  believe there has been some discussion on this, that I have not been able to
  follow completely, so ignore if already discussed and agreed upon.

- The term "supporter" is used for two things where it's not clear if
  it's the same:

    1. People listed as supporters in the RFC metadata.
    2. Team members that respond with "I support" during the Deliberation
       Period.

  Furthermore, in the section "Submission Period" it says that authors
  can look for supporters. But the wording in the "Deliberation Period"
  suggests that the "I support" emails should only be sent in the
  Deliberation Period when the final version is published.
  
  For example: Ricardo replied with "I support". What does that mean when the
  Deliberation Period has not yet started?

  I think what is meant is that supporters can be recruited at any time
  and team members responding during the Deliberation Period with "I
  support" become supporters and will be added to the list of supporters
  in the metadata. This should be clarified.

- The term "final" is overloaded and underused:

  1. "Final" is a state of an RFC.
  2. In section "Discussion Period" the authors should publish a "final"
     version. But this is not a RFC that has state "Final".
  3. In section "Deliberation Period" a valid response by team members is "I
     accept". The RFC is also described as "accepted". The term for the state
     "Final" is not used.
     
  I'd suggest renaming the RFC state "Final" to "Accepted".
  
- In Section "Deliberation Period" the team member response is "I disapprove"
  but in the next section the term "disagree" is used. I'd use the same term for
  clarity.

- The "I disapprove" reply is only allowed if member actively proposed
  alternative solutions during the "Discussion Period". I feel that might be a
  bit of a strong requirement as that means you can not disapprove a RFC if you
  only see it after the "Deliberation Period" has started. Maybe that's ok as
  RFCs need to be announced to guix-devel. Still it might be a bit strong. Maybe
  something along the lines: "A team member sending this reply must explain
  their disapproval and should suggest constructive changes to the proposal that
  would make it approvable."

- I think the name "Guix Consensus Documents (GCD)" would be slightly
  funnier - a play on greatest common divisor (as mentioned by Simon).
  But I think RFC is a term that is more widely understood and that's
  fine.
  
I'm not quite clear what this means, but: I support. :) 

I will be afk during the Deliberation Period (and not present in
Brussels) but I think this is an important step for Guix and am fine
with being added to the `supporters` field.

-pukkamustard

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

[Simon Tournier]

Hi,

On Wed, 08 Jan 2025 at 16:26, "pukkamustard" <pukkamustard@posteo.net> wrote:

> - I had to think if I am a _team member_ or not. The term is not defined in the
>   document. I think this is mostly due to there not being a RFC on teams (yet).
>   Still, to make the Process RFC understandable, I'd add a brief explanation of
>   what team members are (i.e. members in etc/teams.scm). 

Yes, that’s the idea.  Ludo pointed that teams.scm file and it was in v5
but not in v6.  Maybe something lost in translation. :-)

>   Likewise, I think the Process RFC would be simpler to understand if feedback
>   is required from a fixed number of team members instead of a percentage. I
>   believe there has been some discussion on this, that I have not been able to
>   follow completely, so ignore if already discussed and agreed upon.

What do you suggest?

Well, FWIW, some explanations, maybe it could help to find a better way.

It appears to me easier to know if the quorum is reached or not, I
guess.

    ./etc/teams.scm list-teams | recsel -CP members | sort | uniq | wc -l

I think that the input of some team members might happen on the
Discussion Period and not specifically on the Deliberation Period.

Well, then you would tell me: I cannot have an opinion on any topic. :-)
Or I do not have the bandwidth to follow all the discussion.  Maybe.
But then, if we are not able to express an opinion on such topic, does
we consent?

From my point of view, the idea is to be sure we – as a community –
consent about significant changes.

And if I – as a deliberating member – do not feel confident enough, I
have two options: (a) Disapprove, for instance because I estimate we
have not discussed enough the topic at hand and the topic deserves more
discussion or another counter proposal or (b) Silent (no reply),
although it would mean to me something is wrong.

On this, the danger is the “social pressure” because the Deliberation
Period is public.  But if it’s a real issue, improvement on that could
be part of an amendment for the next version. :-)

Please keep in mind (1) the “social pressure” would mean it’s not a safe
place hence it would raise more than the potential RFC and (2) consent
does not mean being 100% in agreement with all the details but it means
“it’s a good direction, not perfect but I can live with the
imperfections”.  Somehow. :-)

> - The term "supporter" is used for two things where it's not clear if
>   it's the same:
>
>     1. People listed as supporters in the RFC metadata.
>     2. Team members that respond with "I support" during the Deliberation
>        Period.

Ah.  Hum.  The idea of the process is:

    + author sends
(*) + one or more people reply “I support”
    + it becomes a submitted RFC
    + all the dance…
    + Deliberation Period:
(**)  . I support
      . I approve
      . I disapprove

Ah indeed (*) and (**) are not the same:

  1. “Supporter” means (*)
  2. Team members replying “I support” means (**)

Thanks.  Maybe (1)(*) should be renamed.


>   I'd suggest renaming the RFC state "Final" to "Accepted".

I agree.

> - In Section "Deliberation Period" the team member response is "I disapprove"
>   but in the next section the term "disagree" is used. I'd use the same term for
>   clarity.

I agree.

> - The "I disapprove" reply is only allowed if member actively proposed
>   alternative solutions during the "Discussion Period". I feel that might be a
>   bit of a strong requirement as that means you can not disapprove a RFC if you
>   only see it after the "Deliberation Period" has started. Maybe that's ok as
>   RFCs need to be announced to guix-devel. Still it might be a bit strong. Maybe
>   something along the lines: "A team member sending this reply must explain
>   their disapproval and should suggest constructive changes to the proposal that
>   would make it approvable."

If you do not see the RFC after the long Discussion Period of 60 days,
then why do you see it in the short Deliberation Period? ;-)

Somehow, we need to bound, else it becomes hard to move forward, IMHO.

Well, I assume good faith, I would like to counter the behaviour: I
sleep during all the discussion where people took the time to polish and
end up with something all agree, and me, I awake up in the last minute
and bang!  That’s unfair, IMHO.

It’s not explicitly mentioned (maybe it should be): I think that any
“submitted” RFC must be advertised via info-guix@gnu.org.

> - I think the name "Guix Consensus Documents (GCD)" would be slightly
>   funnier - a play on greatest common divisor (as mentioned by Simon).
>   But I think RFC is a term that is more widely understood and that's
>   fine.

I agree.  I remember your suggestion at the last Guix Days.  And I lost
it among other stuff during the year 2024… Arf!

> I'm not quite clear what this means, but: I support. :) 
>
> I will be afk during the Deliberation Period (and not present in
> Brussels) but I think this is an important step for Guix and am fine
> with being added to the `supporters` field.

Thank you.

Ah what a pity to not see you in Brussels!

Cheers,
simon

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

[Ludovic Courtès]

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Ah.  Hum.  The idea of the process is:
>
>     + author sends
> (*) + one or more people reply “I support”
>     + it becomes a submitted RFC
>     + all the dance…
>     + Deliberation Period:
> (**)  . I support
>       . I approve
>       . I disapprove
>
> Ah indeed (*) and (**) are not the same:
>
>   1. “Supporter” means (*)
>   2. Team members replying “I support” means (**)
>
> Thanks.  Maybe (1)(*) should be renamed.

How about “sponsors”?  (I believe I’ve seen it in other similar
documents.)

Ludo’.

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

[Ludovic Courtès]

Hello pukkamustard,

Thanks for insightful comments!

"pukkamustard" <pukkamustard@posteo.net> skribis:

> - I had to think if I am a _team member_ or not. The term is not defined in the
>   document. I think this is mostly due to there not being a RFC on teams (yet).
>   Still, to make the Process RFC understandable, I'd add a brief explanation of
>   what team members are (i.e. members in etc/teams.scm). 

A mistake of mine in v6; we should reintroduce a mention of
‘etc/teams.scm’ or a reference to the manual.

>   Likewise, I think the Process RFC would be simpler to understand if feedback
>   is required from a fixed number of team members instead of a percentage.

Wouldn’t a fixed number of people run the risk of letting a few people
move forward despite general apathy?  (Given that that fixed number
might represent 25% of team members today, and 5% a few years from now.)

> - The term "supporter" is used for two things where it's not clear if
>   it's the same:
>
>     1. People listed as supporters in the RFC metadata.
>     2. Team members that respond with "I support" during the Deliberation
>        Period.

Yeah, “sponsors” may work better for (1).

>   Furthermore, in the section "Submission Period" it says that authors
>   can look for supporters. But the wording in the "Deliberation Period"
>   suggests that the "I support" emails should only be sent in the
>   Deliberation Period when the final version is published.

We could state that anything that comes before or after the Deliberation
Period is ignored, to avoid the ambiguity.

>   I'd suggest renaming the RFC state "Final" to "Accepted".

Agreed (that was an omission).

> - In Section "Deliberation Period" the team member response is "I disapprove"
>   but in the next section the term "disagree" is used. I'd use the same term for
>   clarity.

Oops, agreed.

> - The "I disapprove" reply is only allowed if member actively proposed
>   alternative solutions during the "Discussion Period". I feel that might be a
>   bit of a strong requirement as that means you can not disapprove a RFC if you
>   only see it after the "Deliberation Period" has started. Maybe that's ok as
>   RFCs need to be announced to guix-devel. Still it might be a bit strong. Maybe
>   something along the lines: "A team member sending this reply must explain
>   their disapproval and should suggest constructive changes to the proposal that
>   would make it approvable."

Hmm yeah, I see what you mean; it shouldn’t be understood as “I
disapprove” is strictly forbidden for people who have not made
counter-proposals during the discussion.  Yet, I agree with Simon that
“I disapprove” should be discouraged in this case.  Probably we can fine
tune the words.

> - I think the name "Guix Consensus Documents (GCD)" would be slightly
>   funnier - a play on greatest common divisor (as mentioned by Simon).
>   But I think RFC is a term that is more widely understood and that's
>   fine.

Heheh.

I’m fine either way but I’m already getting used to “RFC”.  :-)

> I will be afk during the Deliberation Period (and not present in
> Brussels) but I think this is an important step for Guix and am fine
> with being added to the `supporters` field.

Thanks.  Too bad we won’t meet in Brussels though.

Ludo’.

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi,

On Mon, 06 Jan 2025 at 23:29, Ludovic Courtès <ludo@gnu.org> wrote:

> title: Requests-for-Comment Process
> id: 000

I think it’s better to start with 001 and have 000 for the template.

> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> supporters: ?
> submitted: 2024-12-12

I think the choice of this date is unclear.  Do you consider that your
reply or mine implies being Supporter?

Well, since this document bootstrap the process it’s difficult. :-)
Especially when the first draft had been sent on 2023-10-31.

I suggest to clarify and to extend:

        > The RFC is *submitted* once it has at least one supporter in addition to
        > the author(s).

with:

        The RFC is *submitted* once it has at least one supporter in
        addition to the author(s).  See Submission Period below.

> date: 2025-01-15
> ---
>
> # Summary

[...]

> # Motivation

[...]

> # Detailed Design
>
> ## When to Follow This Process

[...]

> ## 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.

I suggest: `XY` increments the sequence number.

> 3. Write your RFC following the template’s 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).

See above.

>
> ## Supporters
>
> A supporter is a contributor sufficiently familiar with the project’s
> 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.

I would add (picked from v5):

        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.

I think that important to have this written somewhere in the document.
And because author is focused on the proposal – if one took the time to
write something, it means one has an idea on some topic that one want to
defend :-) –, then it might be difficult to have the right distance.
Hence Supporter(s) are also the helper / facilitator here.

> ## Timeline
>
> The lifetime of an RFC is structured into the following recommended
> periods:
>
> ![diagram.svg](Diagram of the RFC process.)

I would replace the node ’comments’ by discussion in order to have
something more homogeneous.  Nitpicking? ;-)

> ```dot <- TODO: make this a separate file

I would prefer to let the dot file here as-is.  Because it’s easier to
read in full terminal mode.  In addition, yes maybe we could display the
graph as an image file.

> digraph "RFC Timeline" {
>     submission[label=<Submission Period<br />up to 7 days>]
>     comments[label=<Discussion Period<br />30–60 days>]

     discussion[label=<Discussion Period<br />30–60 days>]

>     deliberation[label=<Deliberation Period<br />14 days>]
>     withdrawn[label=Withdrawn, shape=rectangle]
>     final[label=Final, shape=rectangle]
>     
>     submission -> comments
>     submission -> withdrawn
>     comments -> deliberation

     discussion -> deliberation

>     deliberation -> withdrawn
>     deliberation -> final
>     
>     withdrawn -> submission [label="New version"]
>     
>     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*.

As said above, I would clarify:

                                 The RFC is *submitted* once one or more
        people publicly reply “I support” and volunteers to be
        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)

[...]

> ### Deliberation Period (14 days)
>
> All members of any team of the Guix project can participate in
> deliberation and are encouraged to do so.

I would restore the past suggestion to mention the file ’teams.scm’; see
suggestion below (mark **).

> 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:
>
> - “I support”, meaning that one supports the proposal);

                                                    ---^
                                                       ) extra

> - “I disapprove”, meaning that one opposes the implementation of the
>   proposal.  A team member sending this reply must have actively
>   proposed alternative solutions during the discussion period.

I do not think the wording of the last sentence is accurate enough:
Because maybe there is no alternative solution or the status quo is the
one, etc.

Instead, I would write:

        A team member sending this reply must have actively cooperated
        with for discussing the RFC during the discussion period. See
        Decision Making.


> 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*.

Here, I would replace ’disagrees’ with ’disapproves’.  It appears to me
clearer.

> Deliberation aims at consolidating consensus; see “Decision Making”
> below.

Here (remember mark ** :-)), I would add this sentence.

        Anyone who is on a team (see file ‘teams.scm’) is a deliberating
        member and is asked to contribute to the deliberation.

> ## Decision Making

[...]

> ## Merging Final RFCs

[...]

>
> ## RFC Template
>
> The expected structure of RFCs is captured by the template in the file
> `0000-template.md`, written in English with Markdown ornaments.

The number of 000 must be in agreement with the top, IMHO.

> ## Cost of Reverting

[...]

> ## Drawbacks

[...]

> ## Open Issues

[...]


Cheers,
simon

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

[Ludovic Courtès]

Hello,

(Stripping comments/suggestions I agree with.)

Simon Tournier <zimon.toutoune@gmail.com> skribis:

>> supporters: ?
>> submitted: 2024-12-12
>
> I think the choice of this date is unclear.  Do you consider that your
> reply or mine implies being Supporter?
>
> Well, since this document bootstrap the process it’s difficult. :-)
> Especially when the first draft had been sent on 2023-10-31.

Yeah, it’s quite arbitrary here, I’m fine with any date.

Obviously it’ll be more important once the process is actually in place.

>> ## Supporters
>>
>> A supporter is a contributor sufficiently familiar with the project’s
>> 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.
>
> I would add (picked from v5):
>
>         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.

You mean that this (soliciting opinions) is something
supporters/sponsors should do, right?  I agree.

>> ```dot <- TODO: make this a separate file
>
> I would prefer to let the dot file here as-is.  Because it’s easier to
> read in full terminal mode.  In addition, yes maybe we could display the
> graph as an image file.

Yeah, I’m split between Dot and ASCII art…

> As said above, I would clarify:
>
>                                  The RFC is *submitted* once one or more
>         people publicly reply “I support” and volunteers to be
>         supporters; the next step is the *discussion period*.

OK.

>> All members of any team of the Guix project can participate in
>> deliberation and are encouraged to do so.
>
> I would restore the past suggestion to mention the file ’teams.scm’; see
> suggestion below (mark **).

Agreed.

I’ll send v7 tomorrow.

Thank you!

Ludo’.

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

[Simon Tournier]

Hi Ludo,

On Thu, 09 Jan 2025 at 23:32, Ludovic Courtès <ludo@gnu.org> wrote:

> Yeah, I’m split between Dot and ASCII art…

Heh me too.  Although the dot provides a bit more information via the
name of the nodes.  Bah I don’t know.


> I’ll send v7 tomorrow.

I have sent a v7 integrating various comments.  Feel free to adjust with
a v8 if I am missing something.

Thank you, almost there I hope. :-)

Cheers,
simon

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

Overall, this seems quite good, nice work all!

I do have one specific comment... though I am a latecomer to this
discussion!

On 2025-01-06, Ludovic Courtès wrote:
> ### 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:
>
> - “I support”, meaning that one supports the proposal);
> - “I accept”, meaning that one consents to the implementation of the
>   proposal;
> - “I disapprove”, meaning that one opposes the implementation 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*.

Is 'no one disagrees' == 'no one replies with "I disapprove"'? It would
be nicer if there were more explicit alignment in the words used to make
that clearer, if that is, in fact, the intended case. Perhaps
literally... e.g. ... (2) if no one declares "I disapprove".

... Well, two points, apparently, now that I got the simple one out of
the way... :)

In other consensus settings I have on occasion declared something that
is effectively "I accept, but I disapprove" or maybe more descriptively
"I accept, with reservations" e.g. not agreeing with the decision but
not severely enough that it should not move forward. You might not
expect to get much help with implementation from such a person, though!

I guess again, it comes to word alignment ... "I disapprove" sounds
rather soft, compared to the effects (e.g. blocking further progress or
sending it back to the proverbial drawing board). "I accept" sounds
rather positive, despite the possibility of some potential discomfort
with the decision...

Obviously, one can and should declare their reservations as part of the
discussion that lead up to that point! Although maybe "I accept" should
come with the option to declare formal outstanding concerns?

Similarly "I disaprove" should not come out of nowhere; it should be
clear why, and perhaps worth having an option to note that in the call
for consensus at the end of the Deliberation Period?


Eeesh. Three points!

I also wonder if there is a supermajority of "I accept" over "I support"
this maybe should raise some sort of red flag calling into question the
proposal... as that is a very weak consensus and perhaps cause for
concern.


All that said, I am a latecomer to this process... so take it however is
most helpful! Overall, it looks quite good to my eyes.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi,

On Thu, 09 Jan 2025 at 16:40, Vagrant Cascadian <vagrant@debian.org> wrote:

> Is 'no one disagrees' == 'no one replies with "I disapprove"'? It would
> be nicer if there were more explicit alignment in the words used to make
> that clearer, if that is, in fact, the intended case. Perhaps
> literally... e.g. ... (2) if no one declares "I disapprove".

I hope it is clarified with v7 [1]:

        The GCD is *accepted* if (1) at least 25% of all team members send a
        reply, and (2) no one disapproves.  In other cases, the GCD is
        *withdrawn*.

WDYT?

Maybe, « (2) if no one declares "I disapprove". » seems even clearer?

> Obviously, one can and should declare their reservations as part of the
> discussion that lead up to that point! Although maybe "I accept" should
> come with the option to declare formal outstanding concerns?

Well, that’s the distinction between “I support” and “I accept”, no?

Somehow, the idea with “I accept” is “I think it’s the good direction
although I have these concerns X and Y but I can with live all that”.

Well, I think these concerns are captured during the “Discussion Period”
and they should be included in the section “Drawback” or “Open Issues”.

WDYT?

> Similarly "I disaprove" should not come out of nowhere; it should be
> clear why, and perhaps worth having an option to note that in the call
> for consensus at the end of the Deliberation Period?

I agree.  Does this wording v7 [1]:

        - “I disapprove”, meaning that one opposes the implementation of the
          proposal.  A team member sending this reply must have actively
          cooperated with for discussing the RFC during the discussion period.
          See “Decision Making”.

answer to your comment?  In addition, “Decision Making” section
contains:

        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.

Therefore, “I disapprove” cannot come out of nowhere because the person
who disapproves must comment during the “Discussion Period” on the why.

That’s said, do you suggest that the reply “I disapprove” during the
“Deliberating Period” should come with a summary about why?

And such summary would be then included in the Document with the state
of ’widthdrawn’.


> I also wonder if there is a supermajority of "I accept" over "I support"
> this maybe should raise some sort of red flag calling into question the
> proposal... as that is a very weak consensus and perhaps cause for
> concern.

Good point.  Maybe this is the same as above about having these concerns
written down in the final document under a dedicated section as
“Drawback” or “Open Issues”.  WDYT?


> All that said, I am a latecomer to this process... so take it however is
> most helpful! Overall, it looks quite good to my eyes.

Thank you for your comments.

Cheers,
simon


1: [bug#74736] [PATCH v7] Add Guix Common Document process.
Simon Tournier <zimon.toutoune@gmail.com>
Fri, 10 Jan 2025 00:45:51 +0100
id:87jzb3h7ps.fsf@gmail.com
https://issues.guix.gnu.org/74736
https://issues.guix.gnu.org/msgid/87jzb3h7ps.fsf@gmail.com
https://yhetil.org/guix/87jzb3h7ps.fsf@gmail.com

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

On 2025-01-10, Simon Tournier wrote:
> On Thu, 09 Jan 2025 at 16:40, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> Is 'no one disagrees' == 'no one replies with "I disapprove"'? It would
>> be nicer if there were more explicit alignment in the words used to make
>> that clearer, if that is, in fact, the intended case. Perhaps
>> literally... e.g. ... (2) if no one declares "I disapprove".
>
> I hope it is clarified with v7 [1]:
>
>         The GCD is *accepted* if (1) at least 25% of all team members send a
>         reply, and (2) no one disapproves.  In other cases, the GCD is
>         *withdrawn*.
>
> WDYT?

Hah. Subtle but meaningful difference! Yes, I think that captures it.

> Maybe, « (2) if no one declares "I disapprove". » seems even clearer?

It does seem clearer, but the match between "I disapprove" and
disapproves is probably sufficient to address my concern.


>> Obviously, one can and should declare their reservations as part of the
>> discussion that lead up to that point! Although maybe "I accept" should
>> come with the option to declare formal outstanding concerns?
>
> Well, that’s the distinction between “I support” and “I accept”, no?

That is my understanding...

> Somehow, the idea with “I accept” is “I think it’s the good direction
> although I have these concerns X and Y but I can with live all that”.

It mashes together "good direction, with concerns" and "good enough
direction, with concerns" and "tolerable direction, with concerns".  It
may not be necessary having those so fine-grained, and being able to
reflect that as part of the concerns raised and noted.


> Well, I think these concerns are captured during the “Discussion Period”
> and they should be included in the section “Drawback” or “Open Issues”.

Sounds good to me, sure!


>> Similarly "I disaprove" should not come out of nowhere; it should be
>> clear why, and perhaps worth having an option to note that in the call
>> for consensus at the end of the Deliberation Period?
>
> I agree.  Does this wording v7 [1]:
>
>         - “I disapprove”, meaning that one opposes the implementation of the
>           proposal.  A team member sending this reply must have actively
>           cooperated with for discussing the RFC during the discussion period.
>           See “Decision Making”.
>
> answer to your comment?  In addition, “Decision Making” section
> contains:
>
>         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.
>
> Therefore, “I disapprove” cannot come out of nowhere because the person
> who disapproves must comment during the “Discussion Period” on the why.
>
> That’s said, do you suggest that the reply “I disapprove” during the
> “Deliberating Period” should come with a summary about why?

I *think* so, even though it should have already been made clear through
earlier discussion that there was an issue... it may not always be
clear, especially with asyncronous communications, what each person
final stance is at the end of those prior discussions.


> And such summary would be then included in the Document with the state
> of ’widthdrawn’.

At least the major points of disapproval should be summarized succinctly
somewhere. I am not terribly particular about where. :)


>> I also wonder if there is a supermajority of "I accept" over "I support"
>> this maybe should raise some sort of red flag calling into question the
>> proposal... as that is a very weak consensus and perhaps cause for
>> concern.
>
> Good point.  Maybe this is the same as above about having these concerns
> written down in the final document under a dedicated section as
> “Drawback” or “Open Issues”.  WDYT?

Yeah, something along those lines.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi,

On Sun, 12 Jan 2025 at 17:45, Vagrant Cascadian <vagrant@debian.org> wrote:

> It mashes together "good direction, with concerns" and "good enough
> direction, with concerns" and "tolerable direction, with concerns".  It
> may not be necessary having those so fine-grained, and being able to
> reflect that as part of the concerns raised and noted.
>
>> Well, I think these concerns are captured during the “Discussion Period”
>> and they should be included in the section “Drawback” or “Open Issues”.
>
> Sounds good to me, sure!

[...]

>>> I also wonder if there is a supermajority of "I accept" over "I support"
>>> this maybe should raise some sort of red flag calling into question the
>>> proposal... as that is a very weak consensus and perhaps cause for
>>> concern.
>>
>> Good point.  Maybe this is the same as above about having these concerns
>> written down in the final document under a dedicated section as
>> “Drawback” or “Open Issues”.  WDYT?
>
> Yeah, something along those lines.

Does it address the comment above about fine-grained “I accept”?


Cheers,
simon

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hello,

> As proposed before, here’s a reworked version based on v5.  The intent
> 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.

[..]

> Thoughts?

> # Motivation

Am I right that the main purpose/intent is (not trying to twist anyone's words)

> 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.

  * to draw more attention to / have important discussions stand out
  more in all the "noise", and guided by

> The RFC process is a mechanism to determine whether a proposed change is
> “significant” enough to require attention from the community at large
> and if so, to provide a documented way to bring about broad community
> discussion and to collectively decide on the proposal.

  * a collective decision on what "important" is?

So, in effect a "noise" filter / focus mechanism for the most important
changes.  That seems like a very good idea to me!

> ## 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.

I have no personal experience with RFC processes and this seems
lightweight enough to begin with.  A drawback could be that it slows
development down, but for important changes that may be a good thing?
Other than that I see only advantages, well done.

The only things that I could suggest is to see if we should make it even
be more lightweight/nimble as a first version, e.g, require only two
*persons*, so that two authors could start a submission

    The RFC is *submitted* once it has at least one co-author or
    supporter in addition to the initial author(s).

or use shorter periods, e.g.

    submission[label=<Submission Period<br />up to 7 days>]
    comments[label=<Discussion Period<br />15–60 days>]
    deliberation[label=<Deliberation Period<br />8-14 days>]

but I have no strong opinion on these.

[..]

> 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.
                                 ^
"long" typo?

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi Janneke,

On Fri, 10 Jan 2025 at 08:44, Janneke Nieuwenhuizen <janneke@gnu.org> wrote:

>> # Motivation
>
> Am I right that the main purpose/intent is (not trying to twist anyone's words)

[...]

>   * to draw more attention to / have important discussions stand out
>   more in all the "noise", and guided by

[...]

>   * a collective decision on what "important" is?

Yes! :-)

>                                    A drawback could be that it slows
> development down, but for important changes that may be a good thing?

I would you say yes :-)

And I would also say it’s a counter measure against “Why wasn't I
consulted“ [1] or some bullet points [2] from the talk that appear to me
helpful and that had been inspiration.

1: https://youtu.be/m0rakUuPXFM
2: https://simon.tournier.info/posts/2023-10-30-toward-rfc.html


> The only things that I could suggest is to see if we should make it even
> be more lightweight/nimble as a first version, e.g, require only two
> *persons*, so that two authors could start a submission
>
>     The RFC is *submitted* once it has at least one co-author or
>     supporter in addition to the initial author(s).

Ah you mean that the case of ’two authors’ does not require a Sponsor*,
right?

*Sponsor: was ’Supporter’ but renamed in order to avoid confusion
 between supporting the Document before the Discussion Period and
 replying ’I support’ during the Delibration Period.

> or use shorter periods, e.g.
>
>     submission[label=<Submission Period<br />up to 7 days>]
>     comments[label=<Discussion Period<br />15–60 days>]
>     deliberation[label=<Deliberation Period<br />8-14 days>]
>
> but I have no strong opinion on these.

About the Discussion Period, I do not have an opinion.  From my
intuition, it appears to be helpful when all have the time and space for
expressing their comments.

About the Deliberation Period, I think we need to have enough time and 2
weeks sound the good range based on what we are already doing for patch
review.

Thanks for the comments.

Cheers,
simon

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Janneke Nieuwenhuizen]

Simon Tournier writes:

Hi Simon,

> On Fri, 10 Jan 2025 at 08:44, Janneke Nieuwenhuizen <janneke@gnu.org> wrote:
>
>>> # Motivation

[..]

>>   * to draw more attention to / have important discussions stand out
>>   more in all the "noise", and guided by

[..]

> Yes! :-)

Great!

>
>>                                    A drawback could be that it slows
>> development down, but for important changes that may be a good thing?
>
> I would you say yes :-)
>
> And I would also say it’s a counter measure against “Why wasn't I
> consulted“ [1] or some bullet points [2] from the talk that appear to me
> helpful and that had been inspiration.
>
> 1: https://youtu.be/m0rakUuPXFM
> 2: https://simon.tournier.info/posts/2023-10-30-toward-rfc.html

Yes, I tend to agree.  Especially improving the chance to get involved
is a very good thing.

>> The only things that I could suggest is to see if we should make it even
>> be more lightweight/nimble as a first version, e.g, require only two
>> *persons*, so that two authors could start a submission
>>
>>     The RFC is *submitted* once it has at least one co-author or
>>     supporter in addition to the initial author(s).
>
> Ah you mean that the case of ’two authors’ does not require a Sponsor*,
> right?

Ah yes,

Possibly I'm splitting hairs here too much.  But ISTM that having one
author and one sponsor being enough, whereas in the situation where an
early sponsor actually contributes to become a second author, they would
now have to go look for a third person.  Dunno.

> *Sponsor: was ’Supporter’ but renamed in order to avoid confusion
>  between supporting the Document before the Discussion Period and
>  replying ’I support’ during the Delibration Period.

Noted.  Sorry for being sloppy with the terms :)

>> or use shorter periods, e.g.
>>
>>     submission[label=<Submission Period<br />up to 7 days>]
>>     comments[label=<Discussion Period<br />15–60 days>]
>>     deliberation[label=<Deliberation Period<br />8-14 days>]
>>
>> but I have no strong opinion on these.
>
> About the Discussion Period, I do not have an opinion.  From my
> intuition, it appears to be helpful when all have the time and space for
> expressing their comments.
>
> About the Deliberation Period, I think we need to have enough time and 2
> weeks sound the good range based on what we are already doing for patch
> review.

Indeed, that mathes.  I was just thinking about a patch that "just
passes the RFC-importance threshold" but could have been applied within
a week because it got a lot of review and attention, then someone
proposes to create an RFC, and then you're automatically looking at
7+30+14 == ~7 weeks.

It's a puzzle indeed.  I was thinking: if "everyone involved" argees it
could be done/decided quicker, policy seems to prevent that.  Otoh, that
protects the "why wasn't I consulted" problem.  So yeah.

If nobody else sees the need to make the first iteration more
lightweight, I'm happy to try this.  Thanks again for your efforts.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#74736] [PATCH v6] Add Request-for-Comments process.

[Simon Tournier]

Hi,

On Fri, 10 Jan 2025 at 14:17, Janneke Nieuwenhuizen <janneke@gnu.org> wrote:

>> Ah you mean that the case of ’two authors’ does not require a Sponsor*,
>> right?
>
> Ah yes,
>
> Possibly I'm splitting hairs here too much.  But ISTM that having one
> author and one sponsor being enough, whereas in the situation where an
> early sponsor actually contributes to become a second author, they would
> now have to go look for a third person.  Dunno.

I don’t know either. :-)

Well, from my point of view, once the proposal is “Submitted”, it means
it had been qualified (2 authors or 1 author + 1 sponsor) and then it
does not matter much if the name appears as author or sponsor; or if
more people become author.

The essential is to have a fruitful “Discussion Period” and then to
cross the final line, IMHO.


> It's a puzzle indeed.  I was thinking: if "everyone involved" agrees it
> could be done/decided quicker, policy seems to prevent that.  Otoh, that
> protects the "why wasn't I consulted" problem.  So yeah.

Yeah, a balance. :-)

I think the process can be refined later if it does not match enough the
way we collaborate.  After all, the aim is to ease the important
decisions and not to add useless bureaucracy “à la française”. ;-)

Cheers,
simon

[bug#74736] Add Request-For-Comment process.

[Ricardo Wurmus]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

I support.

This is an important step towards formalizing consent-based decision
making.  Our community has become too big to do without an explicit
process along these lines.  Thank you for making the effort to lay out
this process!  This specific implementation also looks good to me.

-- 
Ricardo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

[bug#74736] [PATCH v7] Add Guix Common Document process.

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

Hi,

Based on v6 and integrating various comments.  Changes:

 • Instead of “Supporter”, the rename is “Sponsor”.

 • Instead of Request-for-Comments (RFC), the rename is Guix Common
   Document (GCD).

 • Fix header: id and SPDX-License-Identifier, adjust sponsor and date.

 • Section “How the Process Works”, point 2. adjust 000-template.md in
   agreement with XYZ.  Mention “Submission Period” and info-guix.

 • Section “Sponsor”: Add paragraph mentioning the role of sponsor.

 • dot graph: Replace ’comments’ by ’discussion’ and ’final’ by
   ’accepted’.

 • Section “Submission Period”: tweak paragraph.

 • Section “Deliberation Period”: tweak “I disapprove” paragraph; Add
   paragraph about deliberating member.

 • Fix trailing dot and replace ornaments by syntax although ornaments
   sound better to my French. ;-)


Please proofread and comment. :-)

WDYT?

Cheers,
simon
--


[-- Attachment #2: 001-gcd-process.md --]
[-- Type: text/markdown, Size: 10020 bytes --]

title: Guix Common Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsor: ?
submitted: 2024-12-08
date: 2025-01-15
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Common Document_ (GCD) process of the
Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
GCD first.

Most day-to-day contributions do *not* require an GCD; 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 “Contributing” chapter.

## How the Process Works

1. Clone https://git.savannah.gnu.org/git/guix/guix-common-document.git #TODO:
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
   is a short descriptive name long and `XYZ` is the sequence number.
3. Write your GCD following the template’s structure.  The GCD 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 GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
   one or more people who will support the GCD and participate in
   discussions by your side (see below).

The GCD is *submitted* once it has at least one sponsor in addition to
the author(s).  See “Submission Period” below.

Submitted GCD is announced at `info-guix@gnu.org`.

## Sponsors

A sponsor is a contributor sufficiently familiar with the project’s
practices, hence it is recommended, but not mandatory, to be a team
member.  Sponsors do not have to agree with all the points of the GCD
but should generally be satisfied that the proposed additions are a good
thing for the community.

Sponsors help the author(s) by participating in discussions, amending
the document as it is being discussed, and acting as timekeepers.

As sponsor, please make sure that all have the time and space for
expressing their comments.  The GCD is about significant changes, thus
more opinions is better than less.

## Timeline

The lifetime of an GCD is structured into the following recommended
periods:

![diagram.svg](Diagram of the GCD process.)

```dot
digraph "GCD Timeline" {
    submission  [label=<Submission Period<br />up to 7 days>]
    discussion  [label=<Discussion Period<br />30–60 days>]
    deliberation[label=<Deliberation Period<br />14 days>]
    withdrawn   [label=Withdrawn, shape=rectangle]
    accepted    [label=Accepted, shape=rectangle]
    
    submission -> discussion
    submission -> withdrawn
    discussion -> deliberation
    deliberation -> withdrawn
    deliberation -> accepted
    
    withdrawn -> submission [label="New version"]
    
    discussion -> withdrawn
}
```

The subsections below detail the various stages and their duration.

### Submission Period (up to 7 days)

Anyone can author and submit an GCD as a regular patch and look for
sponsor (see below). The GCD is *submitted* once one or more people
publicly reply “I sponsor” and volunteers to be sponsors; the next
step is the *discussion period*.

Author(s) may withdraw their GCD at any time; they can resubmit it again
later, possibly under a new GCD number.

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD 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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply must have actively
  cooperated with for discussing the RFC during the discussion period.
  See “Decision Making”.

The GCD is *accepted* if (1) at least 25% of all team members send a
reply, and (2) no one disapproves.  In other cases, the GCD is
*withdrawn*.

Deliberation aims at consolidating consensus; see “Decision Making”
below.

Anyone who is a team member is a deliberating member and is asked
to contribute to the deliberation.  Team members are defined by the
file etc/teams.scm (see “Teams” in the manual).

GCD 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 GCD 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 GCDs

Whether it is accepted or withdrawn, a committer merges the final GCD
following these steps:

1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
   `status` header accordingly);
2. committing everything;
3. announcing the publication of the GCD.

All the GCDs 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).

## GCD Template

The expected structure of GCDs is captured by the template in the file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

The GCD process described in this documented can be amended by
subsequent GCDs.

## 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.

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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

[bug#74736] [PATCH v8] Add Request-For-Comment process.

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

Hello Simon and all,

Here’s v8 (based on changes I had made to v6) to account for the many
good suggestions that were made in the past few days.

Main changes:

  • New “Roles” section (replacing “Supporters”), where “team member” is
    defined.

  • Mention cancellation when sponsors are not found.

  • ASCII art for the diagram.

  • Clarify that it is up to the author(s) to decide when to stop the
    discussion period and start the deliberation period, as long as it’s
    between 30 and 60 days.

  • Regarding disapproval, change “must have …” to “should …”.

As for the name, I was fine with “RFC”, I’m fine with “Guix Consensus
Document” (as pukkamustard suggested), but I would rather avoid “Guix
Common Document”, which IMO fails to convey what this is about.

Find v8 attached and a diff compared to v7, for clarity (?).

I’ll refrain from sending any new version!

BTW, should we start using a version control tool?  We have to file a
Savannah support request to rename the repo though, if there’s consensus
about one of the “GCD” names.

Ludo’.

v7-to-v8 diff:


[-- Attachment #2: Type: text/x-patch, Size: 9027 bytes --]

--- /home/ludo/doc/guix/001-gcd-process.md	2025-01-10 17:47:35.269850711 +0100
+++ /home/ludo/doc/guix/001-gcd-process-v2.md	2025-01-10 18:07:43.556236460 +0100
@@ -1,17 +1,17 @@
-title: Guix Common Document Process
+title: Guix Consensus Document Process
 id: 001
 status: submitted
 discussion: https://issues.guix.gnu.org/74736
 authors: Simon Tournier, Noé Lopez, Ludovic Courtès
-sponsor: ?
-submitted: 2024-12-08
+sponsors: pukkamustard, Ricardo Wurmus
+date-submitted: 2024-12-12
 date: 2025-01-15
 SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
 ---
 
 # Summary
 
-This document describes the _Guix Common Document_ (GCD) process of the
+This document describes the _Guix Consensus Document_ (GCD) process of the
 Guix project.  The GCD 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
@@ -58,7 +58,7 @@
 Someone submitting a patch for any such change may be asked to submit an
 GCD first.
 
-Most day-to-day contributions do *not* require an GCD; examples include:
+Most day-to-day contributions do *not* require a GCD; examples include:
 
 - adding or updating packages, removing outdated packages;
 - fixing security issues and bugs in a way that does not change
@@ -72,9 +72,10 @@
 
 ## How the Process Works
 
-1. Clone https://git.savannah.gnu.org/git/guix/guix-common-document.git #TODO:
+1. Clone
+   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
-   is a short descriptive name long and `XYZ` is the sequence number.
+   is a short descriptive name and `XYZ` is the sequence number.
 3. Write your GCD following the template’s structure.  The GCD 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
@@ -89,58 +90,62 @@
 
 Submitted GCD is announced at `info-guix@gnu.org`.
 
-## Sponsors
+## Roles
 
-A sponsor is a contributor sufficiently familiar with the project’s
-practices, hence it is recommended, but not mandatory, to be a team
-member.  Sponsors do not have to agree with all the points of the GCD
-but should generally be satisfied that the proposed additions are a good
-thing for the community.
-
-Sponsors help the author(s) by participating in discussions, amending
-the document as it is being discussed, and acting as timekeepers.
-
-As sponsor, please make sure that all have the time and space for
-expressing their comments.  The GCD is about significant changes, thus
-more opinions is better than less.
+  - An *author* is the person or one of the persons submitting the RFC.
+    Authors bear the responsibility to carry out the process to its
+    conclusion.
+
+  - A *sponsor* is a contributor who, during the submission period (see
+    below), informs the author(s) that they would like to support the
+    RFC by participating in discussions, providing constructive comments
+    to help the author(s), soliciting opinions, and acting as
+    timekeepers.
+
+    Sponsors should be contributors who consider being sufficiently
+    familiar with the project’s practices; hence it is recommended, but
+    not mandatory, to be a team member.
+
+  - A *team member* is the member of a team, as defined by the Guix
+    project in the manual.  Currently, the list of teams and their
+    members is maintained in the file `etc/teams.scm` in the Guix
+    repository.
 
 ## Timeline
 
-The lifetime of an GCD is structured into the following recommended
-periods:
+A GCD must follow the process illustrated by the diagram below,
+consisting of several *periods*.
 
-![diagram.svg](Diagram of the GCD process.)
 
-```dot
-digraph "GCD Timeline" {
-    submission  [label=<Submission Period<br />up to 7 days>]
-    discussion  [label=<Discussion Period<br />30–60 days>]
-    deliberation[label=<Deliberation Period<br />14 days>]
-    withdrawn   [label=Withdrawn, shape=rectangle]
-    accepted    [label=Accepted, shape=rectangle]
-    
-    submission -> discussion
-    submission -> withdrawn
-    discussion -> deliberation
-    deliberation -> withdrawn
-    deliberation -> accepted
-    
-    withdrawn -> submission [label="New version"]
-    
-    discussion -> withdrawn
-}
+```
+                         +-----------+
+          +- - - - - - ->| Withdrawn |<----------------------+
+          :              +-----------+                       |
+          :                    ^                             |
+          :                    :                             |
++--------------------+   +---------------------+   +---------------------+
+| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
+|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
++--------------------+   +---------------------+   +---------------------+
+                                                             |
+                                                             |
+                                                             V
+                                                       +----------+
+                                                       | Accepted |
+                                                       +----------+
 ```
 
-The subsections below detail the various stages and their duration.
+The subsections below detail the various periods and their duration.
 
 ### Submission Period (up to 7 days)
 
-Anyone can author and submit an GCD as a regular patch and look for
-sponsor (see below). The GCD is *submitted* once one or more people
-publicly reply “I sponsor” and volunteers to be sponsors; the next
-step is the *discussion period*.
+Anyone can author and submit a GCD as a regular patch and look for
+sponsors (see below).  The GCD is *submitted* once one or more people
+have volunteered to be sponsors by publicly replying “I sponsor”; it is
+canceled if no sponsor could be found during that period.  The next step
+is the *discussion period*.
 
-Author(s) may withdraw their GCD at any time; they can resubmit it again
+Authors may withdraw their GCD at any time; they can resubmit it again
 later, possibly under a new GCD number.
 
 ### Discussion Period (at least 30 days, up to 60 days)
@@ -148,13 +153,14 @@
 Once submitted, the GCD 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*.
+When deemed appropriate, between 30 days and 60 days after the start
+of the discussion period, the author(s) may publish a final version and
+announce the start of 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.
+All team members 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 GCD:
@@ -163,9 +169,8 @@
 - “I accept”, meaning that one consents to the implementation of the
   proposal;
 - “I disapprove”, meaning that one opposes the implementation of the
-  proposal.  A team member sending this reply must have actively
-  cooperated with for discussing the RFC during the discussion period.
-  See “Decision Making”.
+  proposal.  A team member sending this reply should have made
+  constructive comments during the discussion period.
 
 The GCD is *accepted* if (1) at least 25% of all team members send a
 reply, and (2) no one disapproves.  In other cases, the GCD is
@@ -174,7 +179,7 @@
 Deliberation aims at consolidating consensus; see “Decision Making”
 below.
 
-Anyone who is a team member is a deliberating member and is asked
+Anyone who is a team member is a deliberating member and is encouraged
 to contribute to the deliberation.  Team members are defined by the
 file etc/teams.scm (see “Teams” in the manual).
 
@@ -219,7 +224,8 @@
 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).
+Texts](https://www.gnu.org/licenses/fdl-1.3.html) or (at your option)
+any later version.
 
 ## GCD Template
 
@@ -228,8 +234,8 @@
 
 ## Cost of Reverting
 
-The GCD process described in this documented can be amended by
-subsequent GCDs.
+The GCD process described in this document can be amended by subsequent
+GCDs.
 
 ## Drawbacks
 

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]


And v8:


[-- Attachment #4: PATCH v8 --]
[-- Type: text/plain, Size: 10789 bytes --]

title: Guix Consensus Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsors: pukkamustard, Ricardo Wurmus
date-submitted: 2024-12-12
date: 2025-01-15
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Consensus Document_ (GCD) process of the
Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
GCD first.

Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.

## How the Process Works

1. Clone
   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
   is a short descriptive name and `XYZ` is the sequence number.
3. Write your GCD following the template’s structure.  The GCD 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 GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
   one or more people who will support the GCD and participate in
   discussions by your side (see below).

The GCD is *submitted* once it has at least one sponsor in addition to
the author(s).  See “Submission Period” below.

Submitted GCD is announced at `info-guix@gnu.org`.

## Roles

  - An *author* is the person or one of the persons submitting the RFC.
    Authors bear the responsibility to carry out the process to its
    conclusion.

  - A *sponsor* is a contributor who, during the submission period (see
    below), informs the author(s) that they would like to support the
    RFC by participating in discussions, providing constructive comments
    to help the author(s), soliciting opinions, and acting as
    timekeepers.

    Sponsors should be contributors who consider being sufficiently
    familiar with the project’s practices; hence it is recommended, but
    not mandatory, to be a team member.

  - A *team member* is the member of a team, as defined by the Guix
    project in the manual.  Currently, the list of teams and their
    members is maintained in the file `etc/teams.scm` in the Guix
    repository.

## Timeline

A GCD must follow the process illustrated by the diagram below,
consisting of several *periods*.


```
                         +-----------+
          +- - - - - - ->| Withdrawn |<----------------------+
          :              +-----------+                       |
          :                    ^                             |
          :                    :                             |
+--------------------+   +---------------------+   +---------------------+
| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
+--------------------+   +---------------------+   +---------------------+
                                                             |
                                                             |
                                                             V
                                                       +----------+
                                                       | Accepted |
                                                       +----------+
```

The subsections below detail the various periods and their duration.

### Submission Period (up to 7 days)

Anyone can author and submit a GCD as a regular patch and look for
sponsors (see below).  The GCD is *submitted* once one or more people
have volunteered to be sponsors by publicly replying “I sponsor”; it is
canceled if no sponsor could be found during that period.  The next step
is the *discussion period*.

Authors may withdraw their GCD at any time; they can resubmit it again
later, possibly under a new GCD number.

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD is publicly discussed; authors are encouraged to
publish updated versions incorporating feedback during the discussion.

When deemed appropriate, between 30 days and 60 days after the start
of the discussion period, the author(s) may publish a final version and
announce the start of the *deliberation period*.

### Deliberation Period (14 days)

All team members 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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply should have made
  constructive comments during the discussion period.

The GCD is *accepted* if (1) at least 25% of all team members send a
reply, and (2) no one disapproves.  In other cases, the GCD is
*withdrawn*.

Deliberation aims at consolidating consensus; see “Decision Making”
below.

Anyone who is a team member is a deliberating member and is encouraged
to contribute to the deliberation.  Team members are defined by the
file etc/teams.scm (see “Teams” in the manual).

GCD 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 GCD 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 GCDs

Whether it is accepted or withdrawn, a committer merges the final GCD
following these steps:

1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
   `status` header accordingly);
2. committing everything;
3. announcing the publication of the GCD.

All the GCDs 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) or (at your option)
any later version.

## GCD Template

The expected structure of GCDs is captured by the template in the file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

The GCD process described in this document can be amended by subsequent
GCDs.

## 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.

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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

[bug#74736] [PATCH v8] Add Request-For-Comment process.

[Simon Tournier]

Hi,

On Fri, 10 Jan 2025 at 18:15, Ludovic Courtès <ludo@gnu.org> wrote:

> As for the name, I was fine with “RFC”, I’m fine with “Guix Consensus
> Document” (as pukkamustard suggested), but I would rather avoid “Guix
> Common Document”, which IMO fails to convey what this is about.

Just to mention that pukkamustard also suggested ’Guix Common Document’
as the previous Guix Days. ;-)  See [1].

Could you explain why “Guix Common Document” fails to convey what this
is about?

That’s said, I’m fine with Guix Consensus Document.  Because even if we
change for another “Decision Making“ strategy as a complex voting
method, the initial idea will be always encoded for ever! :-)

1: [post Guix Days] Guix Common Document (was: Request-For-Comment process)
Simon Tournier <zimon.toutoune@gmail.com>
Sat, 03 Feb 2024 11:34:13 +0100
id:87y1c1kfa2.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-02
https://yhetil.org/guix/87y1c1kfa2.fsf@gmail.com

> +  - A *sponsor* is a contributor who, during the submission period (see
> +    below), informs the author(s) that they would like to support the
> +    RFC by participating in discussions, providing constructive comments
> +    to help the author(s), soliciting opinions, and acting as
> +    timekeepers.
> +
> +    Sponsors should be contributors who consider being sufficiently
> +    familiar with the project’s practices; hence it is recommended, but
> +    not mandatory, to be a team member.

I would add:

        As sponsor, please make sure that all have the time and space for
        expressing their comments.  The GCD is about significant changes, thus
        more opinions is better than less.

or something along these lines.  Because it appears to me important that
we write down that.

WDYT?

Cheers,
simon

[bug#74736] [PATCH v8] Add Request-For-Comment process.

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Could you explain why “Guix Common Document” fails to convey what this
> is about?

“Document” is very broad, and “common” is hard for me to understand in
this context: common to whom? to what? can there more than one “common
document”?  The phrase “common document” doesn’t convey that this is
about proposing changes and deciding on them.

“Request for comment” shows upfront that it’s about soliciting opinions.

“Consensus document” suggests that it’s about documenting the outcome of
a decision making process.

>> +  - A *sponsor* is a contributor who, during the submission period (see
>> +    below), informs the author(s) that they would like to support the
>> +    RFC by participating in discussions, providing constructive comments
>> +    to help the author(s), soliciting opinions, and acting as
>> +    timekeepers.
>> +
>> +    Sponsors should be contributors who consider being sufficiently
>> +    familiar with the project’s practices; hence it is recommended, but
>> +    not mandatory, to be a team member.
>
> I would add:
>
>         As sponsor, please make sure that all have the time and space for
>         expressing their comments.  The GCD is about significant changes, thus
>         more opinions is better than less.

I think the second sentence is redundant with what is written elsewhere:
that it applies to significant changes, and that it’s about soliciting
opinions (and I think it’s important to keep each section to-the-point.)

I’m fine with the first one though.

(“As a sponsor”, with the article “a”.)

Thanks,
Ludo’.

[bug#74736] [PATCH v8] Add Request-For-Comment process.

[Simon Tournier]

Hi,

On Thu, 16 Jan 2025 at 10:00, Ludovic Courtès <ludo@gnu.org> wrote:

> “Consensus document” suggests that it’s about documenting the outcome of
> a decision making process.

Thanks for explaining.

> I’m fine with the first one though.
>
> (“As a sponsor”, with the article “a”.)

Noted.

Thanks,
simon

[bug#74736] Re v8 of Add Request-For-Comment process.

[Hartmut Goebel]

[-- Attachment #1: Type: text/html, Size: 3803 bytes --]

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

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> being late to the discussion, here are my 2 cent. Please apologize if things have already been discussion and decided.

No worries, we still have a bit of time to discuss, thanks for chiming in!

I agree with most of your suggestions/comments.  I’ll just comment where
deserved:

> Section "How the Process Works", number 3: I don't understand "must not be prospective". According to dict.leo.org, "prospective"
> translates in German to adjectives like long-sighted put also to in the future, estimated, likley.

This is meant to suggest (I believe) that the process is not meant as a
way to brainstorm new ideas; instead, it should be applied to ideas that
we roughly know how to implement.

> Section "Roles", Sponsor: "is a contributor" and "should be a contributor". Contributor to the GCD or to Guix? What makes one a
> "contributor"? Is the term defined somewhere else, e.g. in the Guix Manual?

It’s not defined; we can add it to “Roles”.

> Section "Submission Period", Withdrawal and Resubmit: Are there any rules  why or when an author may resubmit the GCD? Is feedback
> like "The idea is good, but a lot of things popped up during discussion, so we need revise the GCD in great parts" a case for this?

It’s up to authors to decide what to do based on the feedback they got
(or lack thereof).  If nobody was willing to sponsor it, then perhaps
it’s a sign that people either disapprove it or are uninterested in it
in its current form.

> Section "Discussion Period": Can the period be extended? What happens if there is still heavy discussion aber 60 days?

It has to be at most 60 days, I think that’s quite clear.

> Section "Deliberate period": IMHO "deliberation" is the wrong term, since the team members send in their votes. I suggest calling it "Voting
> Period", even if someone might argue that in consent based decision making, "deliberation" is the term to use.

I proposed “Voting Period” but we eventually considered that
“Deliberation Period” would better represent what this is.

> Section "Deliberate period":The 25% are to be counted at which valuation date? I propose: 

You propose what? :-)

Thanks,
Ludo’.

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

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Hi Ludo,

Am 13.01.25 um 22:17 schrieb Ludovic Courtès:
> Hartmut Goebel<h.goebel@crazy-compilers.com> skribis:
>
>
>> Section "Deliberate period": IMHO "deliberation" is the wrong term, since the team members send in their votes. I suggest calling it "Voting
>> Period", even if someone might argue that in consent based decision making, "deliberation" is the term to use.
> I proposed “Voting Period” but we eventually considered that
> “Deliberation Period” would better represent what this is.

After reading <https://issues.guix.gnu.org/issue/74736#70> I now 
understood that the base idea behind decision making is "Consensus". 
This is mentioned in "motivation", but rather like a side note than as 
an important principle.

Therefore I propose moving the section "Decision Making" into 
"Motivation" – or make it a top-level section just below "Motivation".

>> Section "Deliberate period":The 25% are to be counted at which valuation date? I propose:
> You propose what? :-)

:-)

"… 25% of all team members – as of the start of the Deliberation Period – …"



-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com               |
|www.crazy-compilers.com | compilers which you thought are impossible |

[-- Attachment #2: Type: text/html, Size: 2611 bytes --]

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

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Hi,

enclosed please find a patch for v9. It proposes descriptions for 
missing states, cases and transitions. I found it easier to create the 
patch than describing what I propose to change.

This patch does *not* include my proposals from my other mails today, 
but new ones.

In addition, I suggest exchanging "Process Overview" and "Roles". I left 
this away to keep the patch small.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

[-- Attachment #2: v9.patch --]
[-- Type: text/x-patch, Size: 4395 bytes --]

--- 001-gcd-process-v9.md	2025-01-16 19:08:54.591520179 +0100
+++ 001-gcd-process-v9-hg.md	2025-01-16 21:34:52.637787901 +0100
@@ -70,7 +70,9 @@
 These day-to-day contributions remain governed by the process described
 by the manual in its “Contributing” chapter.
 
-## How the Process Works
+# How the Process Works
+
+## Getting Started
 
 1. Clone
    https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
@@ -85,10 +87,8 @@
    one or more people who will support the GCD and participate in
    discussions by your side (see below).
 
-The GCD is *submitted* once it has at least one sponsor in addition to
-the author(s).  See “Submission Period” below.
-
-Submitted GCD is announced at `info-guix@gnu.org`.
+Your GCD is now in "draft" state and will be processed as described in
+the next sections.
 
 ## Roles
 
@@ -116,7 +116,7 @@
     translation, reviewing, etc. and more broadly any person feeling part
     of the Guix community.
 
-## Timeline
+## Process Overview
 
 A GCD must follow the process illustrated by the diagram below,
 consisting of several *periods*.
@@ -141,18 +141,36 @@
 
 The subsections below detail the various periods and their duration.
 
-### Submission Period (up to 7 days)
+## Submission Period (up to 7 days)
+
+During the Submission Period the authors seek at least one sponsor
+(see below) for their *draft* GCD in addition to the author(s).
+Contributors can volunteer to be sponsors by publicly replying “I
+sponsor” to the authors' announcement.
 
-Anyone can author and submit a GCD as a regular patch and look for
-sponsors (see below).  The GCD is *submitted* once one or more people
-have volunteered to be sponsors by publicly replying “I sponsor”; it is
-canceled if no sponsor could be found during that period.  The next step
-is the *discussion period*.
+Once one or more sponsors are found, the authors can *submit* the GCD
+(see below) and start the *discussion period*.
+
+The GCD is *canceled* if no sponsor could be found during that period.
 
 Authors may withdraw their GCD at any time; they can resubmit it again
 later, possibly under a new GCD number.
 
-### Discussion Period (at least 30 days, up to 60 days)
+### Submitting the GCD
+
+[[Some explanation like "Merging the Final GCD".
+Plus handling the case that the author disappears:]]
+
+The *discussion period* shall be started within 7 days after
+submission.  After that, the stale GCD may be set to *withdrawn* by a
+Maintainer of the Guix project.
+
+
+## Discussion Period (at least 30 days, up to 60 days)
+
+The *discussion period* starts when the authors
+announce the submission of the GCD at both `info-guix@gnu.org`
+and `guix-devel@gnu.org`.
 
 Once submitted, the GCD is publicly discussed by all the members of the
 community.  Authors are encouraged to publish updated versions
@@ -164,7 +182,14 @@
 of the discussion period, the author(s) may publish a final version and
 announce the start of the *deliberation period*.
 
-### Deliberation Period (14 days)
+The *deliberation period* shall be started within 7 days after the end
+of the discussion period.  After that, the stale GCD may be set to
+*withdrawn* by a Maintainer of the Guix project.
+
+## Deliberation Period (14 days)
+
+The *deliberation period* starts when the authors
+publish a final version of the GCD at `guix-devel@gnu.org`.
 
 Deliberation aims at consolidating consensus; see “Decision Making”
 below.
@@ -230,17 +255,19 @@
 Texts](https://www.gnu.org/licenses/fdl-1.3.html) or (at your option)
 any later version.
 
-## GCD Template
+# Related Documents
+
+* **GCD Template**:
 
 The expected structure of GCDs is captured by the template in the file
 `000-template.md`, written in English with Markdown syntax.
 
-## Cost of Reverting
+# Cost of Reverting
 
 The GCD process described in this document can be amended by subsequent
 GCDs.
 
-## Drawbacks
+# 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
@@ -251,7 +278,7 @@
 and notably avoid repeating arguments, avoid using exclusionary jargon,
 and solicit opinions of those who remained silent.
 
-## Open Issues
+# 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

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

[Simon Tournier]

Hi,

On Thu, 16 Jan 2025 at 21:41, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:

> This patch does *not* include my proposals from my other mails today, 
> but new ones.
>
> In addition, I suggest exchanging "Process Overview" and "Roles". I left 
> this away to keep the patch small.

I tried to include all of the suggestions with v10.  WDYT?

Cheers,
simon

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

[Simon Tournier]

Hi,

On Thu, 16 Jan 2025 at 20:43, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:

> After reading <https://issues.guix.gnu.org/issue/74736#70> I now 
> understood that the base idea behind decision making is "Consensus". 
> This is mentioned in "motivation", but rather like a side note than as 
> an important principle.
>
> Therefore I propose moving the section "Decision Making" into 
> "Motivation" – or make it a top-level section just below "Motivation".

When reading, I said yes why not.  Then re-reading after moving, I
thought that “Decision Making” is a component of the “Detailed Design”.


> "… 25% of all team members – as of the start of the Deliberation Period – …"

Thanks, I agree that it clarifies.

Cheers,
simon

[bug#74736] Re v8 of Add Request-For-Comment process.

[Simon Tournier]

Hi,

Thanks for your comments.

On Sun, 12 Jan 2025 at 16:57, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:

> Section "How the Process Works", number 2: Is –sequence number obvious
> enough? If the GCD is not pushed to the repo right after creating,
> other authors need to look at the patches-mailinglist.

The “sequence number“ of GCD is incremented once the proposal is
‘Submitted’.  Once ’Submitted’, the GCD process ends with two potential
states: accepted or withdrawn.

> Section "How the Process Works", number 3: I don't understand "must
> not be prospective". According to dict.leo.org, "prospective"
> translates in German to adjectives like long-sighted put also to in
> the future, estimated, likley.

The complete sentence reads: « The GCD must not be prospective; it must
formalize an idea and sketch a plan to implement it, even if not all
details are known. ».  Because the GCD must not be a brainstorming
session or a vague idea but a concrete proposal.

Well, I am not native and ‘prospective’ sounds close to French. :-)
Maybe native speaker might say whether that’s the correct term for the
idea behind.

> Section "How the Process Works", number 4: It should be states
> explicitly that the patch is for/against guix-consensus-documents.

I’m not sure to get the comment.  Is it not clear with

 1. Clone https://…/guix-consensus-documents.git 

?

> Section "Roles", Sponsor: "is a contributor" and "should be a
> contributor". Contributor to the GCD or to Guix? What makes one a
> "contributor"? Is the term defined somewhere else, e.g. in the Guix
> Manual?

Indeed, thanks.

> Section "Timelime", Flowshart: Some kind of "declined" is missing.

Updated.

> Section "Submission Period": withdraw and can resubmit "possibly under
> a new GCD number". Why possibly? What are the rules whether a new
> number has to be used?

Once the GCD is “Submitted”, it ends with the state either “Accepted” or
“Widthdrawn”.  Therefore, if a “Submitted” GCD is “Widthdrawn”, then a
new “Submission” gets a new number (if the new becomes “Submitted”).

That’s the idea.

> Section "Submission Period", Withdrawal and Resubmit: Are there any
> rules why or when an author may resubmit the GCD? Is feedback like
> "The idea is good, but a lot of things popped up during discussion, so
> we need revise the GCD in great parts" a case for this?

It seems up to the authors, no?  And it depends on why author withdrawn
before the “Deliberation Period”.

> Section "Discussion Period": Can the period be extended? What happens
> if there is still heavy discussion aber 60 days?

IMHO, it’s better if we keep a bounded period.  Somehow, if after 60
days we are not able to have a consensus, it means the idea is not ready
yet.  Based on this output, nothing prevent to resubmit later once new
and a fresh point of view comes in.

> Section "Deliberate period": IMHO "deliberation" is the wrong term,
> since the team members send in their votes. I suggest calling it
> "Voting Period", even if someone might argue that in consent based
> decision making, "deliberation" is the term to use.

I prefer the term ’deliberation’, from dictionary:

+ Deliberation is the long and careful consideration of a subject.
+ Deliberations are formal discussions where an issue is considered
  carefully.

And, to me the term ’vote’ implies to pick a method for voting.

Well, if ’vote’ is preferred over ’deliberation’, then I would suggest:
“Consensus Voting Period” to make it clear that’s only the concise
expression of what happened during the “Discussion Period”.


> Section "Deliberate period":The 25% are to be counted at which
> valuation date? I propose:

Is something lost in translation? :-)

> Section "Deliberate period": The sentence "Deliberation aims to …"
> should be moved near the beginning of the section.

I agree.

> Section "Deliberate period":Same for "Anyone who is a team member..."

I agree.  And the same idea appeared twice, hence cleaned up.

> Section "Deliberate period": "GCD acceptence" and "withdrawal does not
> necessarily" should go out of this section into as more general
> part. Mayby into "Decision Making" (see my next point on this).

I do not know…

> Section "Deliberate period": IMHO if a vast number of team members
> disapprove the proposal it should be taken as rejected.

There is no formal distinction between ’withdrawn’ because the author
decides to do so or because the consensus leads to a disparagement.

Maybe we could introduce that have four potential states for the GCD
(accepted or deprecated, rejected, withdrawn).

> Section "Decision Making": should go in front of "Timeline", since it
> describes the principle.

I do not have any opinion.


Cheers,
simon

[bug#74736] Re v8 of Add Request-For-Comment process.

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 5431 bytes --]

Hi,

tanks for the updated version.

> On Sun, 12 Jan 2025 at 16:57, Hartmut Goebel<h.goebel@crazy-compilers.com> wrote:
>
>> Section "How the Process Works", number 2: Is –sequence number obvious
>> enough? If the GCD is not pushed to the repo right after creating,
>> other authors need to look at the patches-mailinglist.
> The “sequence number“ of GCD is incremented once the proposal is
> ‘Submitted’.

The current text does not state this. Rather it implies, the sequence 
number is to be picked when creating the draft ("How the Process Works", 
number 2). So if two persons draft a GCD at nearly the same time, how to 
prevent both are picking the same number? (See proposal below.)

It also came to my mind, that the text does not explain who is pushing 
the patch to the GCD repo and when (at which point in the process). 
Proposed text:

    At the end of section "Submission Period":

    If the proposal is "submitted", the author updates the sequence
    number and the state in the patch, applies the patch and pushes the
    change to the main branch of the GCD repo. The commit message should
    read "Submit GCD XYZ: Short Title". See "Merging The (final) GCD)".
    — The next step is the *discussion period*.

    If the proposal is "canceled" or "withdrawn", the author closes the
    "guix-patches" issue and nothing is pushed to the GCD repo. The
    process ends here.

> The complete sentence reads: « The GCD must not be prospective; it must
> formalize an idea and sketch a plan to implement it, even if not all
> details are known. ».  Because the GCD must not be a brainstorming
> session or a vague idea but a concrete proposal.
>
> Well, I am not native and ‘prospective’ sounds close to French. :-)

I'm not native either and I simply don't understand the meaning of "not 
be prospective" - even in conjunction with the remaining part. I suggest 
to either use a different less eloquent wording, rephrase it like you 
did, or as a last resort, remove this phrase.

Also for me "formalize" sounds like the wrong term, as it translates to 
"write a [math, chemistry, etc.] formula", "make official" or "fix in a 
contract". Anyhow, this is what shall be expressed?

Proposal:

    The GCD must describe a concrete idea and sketch a plan to implement
    it, even if not all details are known. The GCD must not be a
    brainstorming session or a vague idea but a concrete proposal.

>> Section "How the Process Works", number 4: It should be states
>> explicitly that the patch is for/against guix-consensus-documents.
> I’m not sure to get the comment.  Is it not clear with
>
>   1. Clone https://…/guix-consensus-documents.git

It was not oblivious to me. This is why I'd rather state i explicitly.

>> Section "Timelime", Flowshart: Some kind of "declined" is missing.
> Updated.

"Canceled" is the term used in "Submission Period". Sorry for the confusion.


>
>> Section "Submission Period": withdraw and can resubmit "possibly under
>> a new GCD number". Why possibly? What are the rules whether a new
>> number has to be used?
> Once the GCD is “Submitted”, it ends with the state either “Accepted” or
> “Widthdrawn”.  Therefore, if a “Submitted” GCD is “Widthdrawn”, then a
> new “Submission” gets a new number (if the new becomes “Submitted”).
>
> That’s the idea.

Thus the word "possibly" (translates to "maybe", "perhaps"), has to be 
removed from the sentence, right?

>> Section "Discussion Period": Can the period be extended? What happens
>> if there is still heavy discussion aber 60 days?
> IMHO, it’s better if we keep a bounded period.  Somehow, if after 60
> days we are not able to have a consensus, it means the idea is not ready
> yet.  Based on this output, nothing prevent to resubmit later once new
> and a fresh point of view comes in.

In <https://issues.guix.gnu.org/issue/74736#58> Ludo wrote: "It has to 
be at most 60 days, I think that’s quite clear."

Either way, this need to be stated more explicit.

>> Section "Deliberate period": "GCD acceptence" and "withdrawal does not
>> necessarily" should go out of this section into as more general
>> part. Mayby into "Decision Making" (see my next point on this).
> I do not know…
>
>> Section "Deliberate period": IMHO if a vast number of team members
>> disapprove the proposal it should be taken as rejected.
> There is no formal distinction between ’withdrawn’ because the author
> decides to do so or because the consensus leads to a disparagement.
>
> Maybe we could introduce that have four potential states for the GCD
> (accepted or deprecated, rejected, withdrawn).
Rethinking this: Since we are seeking consensus, it does not actually 
matter whether the GCD was rejected or withdrawn.

And some new points:

Section "Merging Final GCDs" puts the burden of updating the meta-date 
and announcing to a committer. Agreed that the author might not have 
commit permissions to the GCD repo. Anyhow many might abstain from 
committing it there in this case :-)

Section "Merging Final GCDs" uses "committer" in terms of "has commit 
permissions to the GCD repo" – which is different from teh definition in 
roles. Thus a different or more specific term should be used here.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com               |
|www.crazy-compilers.com | compilers which you thought are impossible |

[-- Attachment #2: Type: text/html, Size: 8945 bytes --]

[bug#74736] Re v8 of Add Request-For-Comment process.

[Simon Tournier]

Hi,

Thanks for your comments.  I included with v10.  WDYT?

On Thu, 16 Jan 2025 at 20:50, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:

> The current text does not state this. Rather it implies, the sequence 
> number is to be picked when creating the draft ("How the Process Works", 
> number 2). So if two persons draft a GCD at nearly the same time, how to 
> prevent both are picking the same number? (See proposal below.)

Well, from my point of view, considering the number of changes requiring
GCD that we did over the past years, I think the situation will not
happen. :-)

Still, how to resolve in practise when that would happen?  I think the
simplest is to consider the sequence order for the final document (the
only that really matters after all) as the first that had been in
*submitted* state using the timestamps of the sponsors.

A good ol’ First In, First Numbered. ;-)

> It also came to my mind, that the text does not explain who is pushing 
> the patch to the GCD repo and when (at which point in the process). 
> Proposed text:
>
>     At the end of section "Submission Period":

It appears to me clearer to separate the concerns.  What do you think
about “Merging GCD”?


> In <https://issues.guix.gnu.org/issue/74736#58> Ludo wrote: "It has to 
> be at most 60 days, I think that’s quite clear."
>
> Either way, this need to be stated more explicit.

I added the *stale* state and how to deal with it.  WDYT?


Cheers,
simon

[bug#74736] [PATCH v9] Add Guix Consensus Document process

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Hi,

Please find attach the v9;  I hope it addresses the comments.

Attached the diff and the document.  The minor changes are:

 • Point alone “1. Clone …”

 • Replace remaining RFC with GCD.

 • Add a sentence about “Sponsor” role.

 • Add the role of “Contributor”.

 • Tweak the artist view of the Timeline

 • Explicit mention that everyone can participate to the “Discussion
   Period”.  And mention that the main concerns and/or opposition are
   collected to the final document.

 • Move upfront the aim of “Deliberation Period”.  Remove a redundant
   sentence.

 • Explicit mention the state ‘deprecated’.


WDYT?

Cheers,
simon

--


[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 6192 bytes --]

diff -u /tmp/001-gcd-process-v8.md /tmp/001-gcd-process-v9.md
--- /tmp/001-gcd-process-v8.md	2025-01-16 16:51:08.758030546 +0100
+++ /tmp/001-gcd-process-v9.md	2025-01-16 18:43:01.835296714 +0100
@@ -73,7 +73,7 @@
 ## How the Process Works

 1. Clone
-   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
+   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
    is a short descriptive name and `XYZ` is the sequence number.
 3. Write your GCD following the template’s structure.  The GCD must not
@@ -92,15 +92,16 @@

 ## Roles

-  - An *author* is the person or one of the persons submitting the RFC.
+  - An *author* is the person or one of the persons submitting the GCD.
     Authors bear the responsibility to carry out the process to its
     conclusion.

   - A *sponsor* is a contributor who, during the submission period (see
     below), informs the author(s) that they would like to support the
-    RFC by participating in discussions, providing constructive comments
+    GCD by participating in discussions, providing constructive comments
     to help the author(s), soliciting opinions, and acting as
-    timekeepers.
+    timekeepers.  As a sponsor, please make sure that all have the time
+    and space for expressing their comments.

     Sponsors should be contributors who consider being sufficiently
     familiar with the project’s practices; hence it is recommended, but
@@ -111,6 +112,10 @@
     members is maintained in the file `etc/teams.scm` in the Guix
     repository.

+  - A *contributor* is a person contributing to Guix either with code,
+    translation, reviewing, etc. and more broadly any person feeling part
+    of the Guix community.
+
 ## Timeline

 A GCD must follow the process illustrated by the diagram below,
@@ -118,21 +123,20 @@


 ```
-                         +-----------+
-          +- - - - - - ->| Withdrawn |<----------------------+
-          :              +-----------+                       |
-          :                    ^                             |
-          :                    :                             |
-+--------------------+   +---------------------+   +---------------------+
-| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
-|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
-+--------------------+   +---------------------+   +---------------------+
-                                                             |
-                                                             |
++--------------------+    +---------------------+   +---------------------+
+| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
+|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
++--------------------+ :  +---------------------+   +---------------------+
+          :            :           :                         |
+          :            v           :                         |
+          :         declined       v                         |
+          :                  o-----------o                   |
+          +- - - - - - - - ->| Withdrawn |<----------------- X
+                             o-----------o                   |
                                                              V
-                                                       +----------+
-                                                       | Accepted |
-                                                       +----------+
+                                                        o----------o
+                                                        | Accepted |
+                                                        o----------o
 ```

 The subsections below detail the various periods and their duration.
@@ -150,8 +154,11 @@

 ### Discussion Period (at least 30 days, up to 60 days)

-Once submitted, the GCD is publicly discussed; authors are encouraged to
-publish updated versions incorporating feedback during the discussion.
+Once submitted, the GCD is publicly discussed by all the members of the
+community.  Authors are encouraged to publish updated versions
+incorporating feedback during the discussion; members are encouraged to
+share a summary of their main concerns or opposition, if any, for being
+included under section “Open Issues” in the document.

 When deemed appropriate, between 30 days and 60 days after the start
 of the discussion period, the author(s) may publish a final version and
@@ -159,8 +166,11 @@

 ### Deliberation Period (14 days)

-All team members can participate in deliberation and are encouraged to
-do so.
+Deliberation aims at consolidating consensus; see “Decision Making”
+below.
+
+Anyone who is a team member is a deliberating member and is encouraged
+to contribute to the deliberation.

 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 GCD:
@@ -176,13 +186,6 @@
 reply, and (2) no one disapproves.  In other cases, the GCD is
 *withdrawn*.

-Deliberation aims at consolidating consensus; see “Decision Making”
-below.
-
-Anyone who is a team member is a deliberating member and is encouraged
-to contribute to the deliberation.  Team members are defined by the
-file etc/teams.scm (see “Teams” in the manual).
-
 GCD 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.
@@ -215,7 +218,7 @@
    `status` to `accepted` or `withdrawn`; adding the URL of the
    discussion in the `discussion` header; updating the `date` header; if
    previously-accepted GCDs are deprecated by this new GCD, change the
-   `status` header accordingly);
+   `status` header accordingly with `deprecated`);
 2. committing everything;
 3. announcing the publication of the GCD.


Diff finished.  Thu Jan 16 18:44:37 2025

[-- Attachment #3: Type: text/plain, Size: 5 bytes --]


--


[-- Attachment #4: GCD --]
[-- Type: text/markdown, Size: 11082 bytes --]

title: Guix Consensus Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsors: pukkamustard, Ricardo Wurmus
date-submitted: 2024-12-12
date: 2025-01-15
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Consensus Document_ (GCD) process of the
Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
GCD first.

Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.

## How the Process Works

1. Clone
   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
   is a short descriptive name and `XYZ` is the sequence number.
3. Write your GCD following the template’s structure.  The GCD 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 GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
   one or more people who will support the GCD and participate in
   discussions by your side (see below).

The GCD is *submitted* once it has at least one sponsor in addition to
the author(s).  See “Submission Period” below.

Submitted GCD is announced at `info-guix@gnu.org`.

## Roles

  - An *author* is the person or one of the persons submitting the GCD.
    Authors bear the responsibility to carry out the process to its
    conclusion.

  - A *sponsor* is a contributor who, during the submission period (see
    below), informs the author(s) that they would like to support the
    GCD by participating in discussions, providing constructive comments
    to help the author(s), soliciting opinions, and acting as
    timekeepers.  As a sponsor, please make sure that all have the time
    and space for expressing their comments.

    Sponsors should be contributors who consider being sufficiently
    familiar with the project’s practices; hence it is recommended, but
    not mandatory, to be a team member.

  - A *team member* is the member of a team, as defined by the Guix
    project in the manual.  Currently, the list of teams and their
    members is maintained in the file `etc/teams.scm` in the Guix
    repository.

  - A *contributor* is a person contributing to Guix either with code,
    translation, reviewing, etc. and more broadly any person feeling part
    of the Guix community.

## Timeline

A GCD must follow the process illustrated by the diagram below,
consisting of several *periods*.


```
+--------------------+    +---------------------+   +---------------------+
| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
+--------------------+ :  +---------------------+   +---------------------+
          :            :           :                         |
          :            v           :                         |
          :         declined       v                         |
          :                  o-----------o                   |
          +- - - - - - - - ->| Withdrawn |<----------------- X
                             o-----------o                   |
                                                             V
                                                        o----------o
                                                        | Accepted |
                                                        o----------o
```

The subsections below detail the various periods and their duration.

### Submission Period (up to 7 days)

Anyone can author and submit a GCD as a regular patch and look for
sponsors (see below).  The GCD is *submitted* once one or more people
have volunteered to be sponsors by publicly replying “I sponsor”; it is
canceled if no sponsor could be found during that period.  The next step
is the *discussion period*.

Authors may withdraw their GCD at any time; they can resubmit it again
later, possibly under a new GCD number.

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD is publicly discussed by all the members of the
community.  Authors are encouraged to publish updated versions
incorporating feedback during the discussion; members are encouraged to
share a summary of their main concerns or opposition, if any, for being
included under section “Open Issues” in the document.

When deemed appropriate, between 30 days and 60 days after the start
of the discussion period, the author(s) may publish a final version and
announce the start of the *deliberation period*.

### Deliberation Period (14 days)

Deliberation aims at consolidating consensus; see “Decision Making”
below.

Anyone who is a team member is a deliberating member and is encouraged
to contribute to the deliberation.

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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply should have made
  constructive comments during the discussion period.

The GCD is *accepted* if (1) at least 25% of all team members send a
reply, and (2) no one disapproves.  In other cases, the GCD is
*withdrawn*.

GCD 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 GCD 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 GCDs

Whether it is accepted or withdrawn, a committer merges the final GCD
following these steps:

1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
   `status` header accordingly with `deprecated`);
2. committing everything;
3. announcing the publication of the GCD.

All the GCDs 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) or (at your option)
any later version.

## GCD Template

The expected structure of GCDs is captured by the template in the file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

The GCD process described in this document can be amended by subsequent
GCDs.

## 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.

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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

[bug#74736] Do you read it? (was: [bug#74736] [PATCH v9] Add Guix Consensus Document process)

[Simon Tournier]

Hi,

The number v9 of my message is superseded by Hartmut message:

        [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
        Hartmut Goebel <h.goebel@crazy-compilers.com>
        Thu, 16 Jan 2025 21:41:26 +0100
        id:d03e9184-f567-4963-85b8-12e93435330c@crazy-compilers.com
        https://issues.guix.gnu.org/74736
        https://issues.guix.gnu.org/msgid/d03e9184-f567-4963-85b8-12e93435330c@crazy-compilers.com
        https://yhetil.org/guix/d03e9184-f567-4963-85b8-12e93435330c@crazy-compilers.com


BTW, that’s weird!  The message with the header below appears in my Sent
folder (Gmail webinterface) but has not reached the list.  Hum?

--8<---------------cut here---------------start------------->8---
Return-Path: <zimon.toutoune@gmail.com>
Received: from lili (roam-nat-fw-prg-194-254-61-41.net.univ-paris-diderot.fr. [194.254.61.41])
        by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c7499884sm68489005e9.5.2025.01.16.10.02.10
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 16 Jan 2025 10:02:11 -0800 (PST)
From: Simon Tournier <zimon.toutoune@gmail.com>
To: 74736@debbugs.gnu.org
Cc: =?utf-8?Q?No=C3=A9?= Lopez <noelopez@free.fr>, Ludovic =?utf-8?Q?Court?=
 =?utf-8?Q?=C3=A8s?= <ludo@gnu.org>,
 Christopher Baines <guix@cbaines.net>, "Artyom V. Poptsov"
 <poptsov.artyom@gmail.com>, Suhail Singh <suhailsingh247@gmail.com>,
 "pukkamustard" <pukkamustard@posteo.net>, Vagrant Cascadian
 <vagrant@debian.org>, Janneke Nieuwenhuizen <janneke@gnu.org>, Ricardo
 Wurmus <rekado@elephly.net>, Hartmut Goebel
 <h.goebel@crazy-compilers.com>, Efraim Flashner <efraim@flashner.co.il>,
 bokr@bokr.com, Andreas Enge <andreas@enge.fr>, GNU Guix maintainers
 <guix-maintainers@gnu.org>
Subject: [bug#74736] [PATCH v9] Add Guix Consensus Document process
In-Reply-To: <cover.1733614983.git.noelopez@free.fr>
References: <cover.1733614983.git.noelopez@free.fr>
Date: Thu, 16 Jan 2025 18:55:53 +0100
Message-ID: <8734hiskwm.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
--8<---------------cut here---------------end--------------->8---

Cheers,
simon

On Thu, 16 Jan 2025 at 18:55, Simon Tournier <zimon.toutoune@gmail.com> wrote:
> Hi,
>
> Please find attach the v9;  I hope it addresses the comments.
>
> Attached the diff and the document.  The minor changes are:
>
>  • Point alone “1. Clone …”
>
>  • Replace remaining RFC with GCD.
>
>  • Add a sentence about “Sponsor” role.
>
>  • Add the role of “Contributor”.
>
>  • Tweak the artist view of the Timeline
>
>  • Explicit mention that everyone can participate to the “Discussion
>    Period”.  And mention that the main concerns and/or opposition are
>    collected to the final document.
>
>  • Move upfront the aim of “Deliberation Period”.  Remove a redundant
>    sentence.
>
>  • Explicit mention the state ‘deprecated’.
>
>
> WDYT?
>
> Cheers,
> simon
>
> --
>
> diff -u /tmp/001-gcd-process-v8.md /tmp/001-gcd-process-v9.md
> --- /tmp/001-gcd-process-v8.md	2025-01-16 16:51:08.758030546 +0100
> +++ /tmp/001-gcd-process-v9.md	2025-01-16 18:43:01.835296714 +0100
> @@ -73,7 +73,7 @@
>  ## How the Process Works
>
>  1. Clone
> -   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
> +   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
>  2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
>     is a short descriptive name and `XYZ` is the sequence number.
>  3. Write your GCD following the template’s structure.  The GCD must not
> @@ -92,15 +92,16 @@
>
>  ## Roles
>
> -  - An *author* is the person or one of the persons submitting the RFC.
> +  - An *author* is the person or one of the persons submitting the GCD.
>      Authors bear the responsibility to carry out the process to its
>      conclusion.
>
>    - A *sponsor* is a contributor who, during the submission period (see
>      below), informs the author(s) that they would like to support the
> -    RFC by participating in discussions, providing constructive comments
> +    GCD by participating in discussions, providing constructive comments
>      to help the author(s), soliciting opinions, and acting as
> -    timekeepers.
> +    timekeepers.  As a sponsor, please make sure that all have the time
> +    and space for expressing their comments.
>
>      Sponsors should be contributors who consider being sufficiently
>      familiar with the project’s practices; hence it is recommended, but
> @@ -111,6 +112,10 @@
>      members is maintained in the file `etc/teams.scm` in the Guix
>      repository.
>
> +  - A *contributor* is a person contributing to Guix either with code,
> +    translation, reviewing, etc. and more broadly any person feeling part
> +    of the Guix community.
> +
>  ## Timeline
>
>  A GCD must follow the process illustrated by the diagram below,
> @@ -118,21 +123,20 @@
>
>
>  ```
> -                         +-----------+
> -          +- - - - - - ->| Withdrawn |<----------------------+
> -          :              +-----------+                       |
> -          :                    ^                             |
> -          :                    :                             |
> -+--------------------+   +---------------------+   +---------------------+
> -| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
> -|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
> -+--------------------+   +---------------------+   +---------------------+
> -                                                             |
> -                                                             |
> ++--------------------+    +---------------------+   +---------------------+
> +| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
> +|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
> ++--------------------+ :  +---------------------+   +---------------------+
> +          :            :           :                         |
> +          :            v           :                         |
> +          :         declined       v                         |
> +          :                  o-----------o                   |
> +          +- - - - - - - - ->| Withdrawn |<----------------- X
> +                             o-----------o                   |
>                                                               V
> -                                                       +----------+
> -                                                       | Accepted |
> -                                                       +----------+
> +                                                        o----------o
> +                                                        | Accepted |
> +                                                        o----------o
>  ```
>
>  The subsections below detail the various periods and their duration.
> @@ -150,8 +154,11 @@
>
>  ### Discussion Period (at least 30 days, up to 60 days)
>
> -Once submitted, the GCD is publicly discussed; authors are encouraged to
> -publish updated versions incorporating feedback during the discussion.
> +Once submitted, the GCD is publicly discussed by all the members of the
> +community.  Authors are encouraged to publish updated versions
> +incorporating feedback during the discussion; members are encouraged to
> +share a summary of their main concerns or opposition, if any, for being
> +included under section “Open Issues” in the document.
>
>  When deemed appropriate, between 30 days and 60 days after the start
>  of the discussion period, the author(s) may publish a final version and
> @@ -159,8 +166,11 @@
>
>  ### Deliberation Period (14 days)
>
> -All team members can participate in deliberation and are encouraged to
> -do so.
> +Deliberation aims at consolidating consensus; see “Decision Making”
> +below.
> +
> +Anyone who is a team member is a deliberating member and is encouraged
> +to contribute to the deliberation.
>
>  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 GCD:
> @@ -176,13 +186,6 @@
>  reply, and (2) no one disapproves.  In other cases, the GCD is
>  *withdrawn*.
>
> -Deliberation aims at consolidating consensus; see “Decision Making”
> -below.
> -
> -Anyone who is a team member is a deliberating member and is encouraged
> -to contribute to the deliberation.  Team members are defined by the
> -file etc/teams.scm (see “Teams” in the manual).
> -
>  GCD 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.
> @@ -215,7 +218,7 @@
>     `status` to `accepted` or `withdrawn`; adding the URL of the
>     discussion in the `discussion` header; updating the `date` header; if
>     previously-accepted GCDs are deprecated by this new GCD, change the
> -   `status` header accordingly);
> +   `status` header accordingly with `deprecated`);
>  2. committing everything;
>  3. announcing the publication of the GCD.
>
>
> Diff finished.  Thu Jan 16 18:44:37 2025
>
> --
>
> title: Guix Consensus Document Process
> id: 001
> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> sponsors: pukkamustard, Ricardo Wurmus
> date-submitted: 2024-12-12
> date: 2025-01-15
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---
>
> # Summary
>
> This document describes the _Guix Consensus Document_ (GCD) process of the
> Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
> “significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
> GCD first.
>
> Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.
>
> ## How the Process Works
>
> 1. Clone
>    https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
> 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
>    is a short descriptive name and `XYZ` is the sequence number.
> 3. Write your GCD following the template’s structure.  The GCD 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 GCD, it must explicitly say so.
> 4. Submit the GCD as a patch to `guix-patches@gnu.org`.
> 5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
>    one or more people who will support the GCD and participate in
>    discussions by your side (see below).
>
> The GCD is *submitted* once it has at least one sponsor in addition to
> the author(s).  See “Submission Period” below.
>
> Submitted GCD is announced at `info-guix@gnu.org`.
>
> ## Roles
>
>   - An *author* is the person or one of the persons submitting the GCD.
>     Authors bear the responsibility to carry out the process to its
>     conclusion.
>
>   - A *sponsor* is a contributor who, during the submission period (see
>     below), informs the author(s) that they would like to support the
>     GCD by participating in discussions, providing constructive comments
>     to help the author(s), soliciting opinions, and acting as
>     timekeepers.  As a sponsor, please make sure that all have the time
>     and space for expressing their comments.
>
>     Sponsors should be contributors who consider being sufficiently
>     familiar with the project’s practices; hence it is recommended, but
>     not mandatory, to be a team member.
>
>   - A *team member* is the member of a team, as defined by the Guix
>     project in the manual.  Currently, the list of teams and their
>     members is maintained in the file `etc/teams.scm` in the Guix
>     repository.
>
>   - A *contributor* is a person contributing to Guix either with code,
>     translation, reviewing, etc. and more broadly any person feeling part
>     of the Guix community.
>
> ## Timeline
>
> A GCD must follow the process illustrated by the diagram below,
> consisting of several *periods*.
>
>
> ```
> +--------------------+    +---------------------+   +---------------------+
> | Submission Period  |    |  Discussion Period  |   | Deliberation Period |
> |  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
> +--------------------+ :  +---------------------+   +---------------------+
>           :            :           :                         |
>           :            v           :                         |
>           :         declined       v                         |
>           :                  o-----------o                   |
>           +- - - - - - - - ->| Withdrawn |<----------------- X
>                              o-----------o                   |
>                                                              V
>                                                         o----------o
>                                                         | Accepted |
>                                                         o----------o
> ```
>
> The subsections below detail the various periods and their duration.
>
> ### Submission Period (up to 7 days)
>
> Anyone can author and submit a GCD as a regular patch and look for
> sponsors (see below).  The GCD is *submitted* once one or more people
> have volunteered to be sponsors by publicly replying “I sponsor”; it is
> canceled if no sponsor could be found during that period.  The next step
> is the *discussion period*.
>
> Authors may withdraw their GCD at any time; they can resubmit it again
> later, possibly under a new GCD number.
>
> ### Discussion Period (at least 30 days, up to 60 days)
>
> Once submitted, the GCD is publicly discussed by all the members of the
> community.  Authors are encouraged to publish updated versions
> incorporating feedback during the discussion; members are encouraged to
> share a summary of their main concerns or opposition, if any, for being
> included under section “Open Issues” in the document.
>
> When deemed appropriate, between 30 days and 60 days after the start
> of the discussion period, the author(s) may publish a final version and
> announce the start of the *deliberation period*.
>
> ### Deliberation Period (14 days)
>
> Deliberation aims at consolidating consensus; see “Decision Making”
> below.
>
> Anyone who is a team member is a deliberating member and is encouraged
> to contribute to the deliberation.
>
> 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 GCD:
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
>   proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
>   proposal.  A team member sending this reply should have made
>   constructive comments during the discussion period.
>
> The GCD is *accepted* if (1) at least 25% of all team members send a
> reply, and (2) no one disapproves.  In other cases, the GCD is
> *withdrawn*.
>
> GCD 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 GCD 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 GCDs
>
> Whether it is accepted or withdrawn, a committer merges the final GCD
> following these steps:
>
> 1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
>    `status` header accordingly with `deprecated`);
> 2. committing everything;
> 3. announcing the publication of the GCD.
>
> All the GCDs 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) or (at your option)
> any later version.
>
> ## GCD Template
>
> The expected structure of GCDs is captured by the template in the file
> `000-template.md`, written in English with Markdown syntax.
>
> ## Cost of Reverting
>
> The GCD process described in this document can be amended by subsequent
> GCDs.
>
> ## 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.
>
> 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’t want the process to become unduly
> burdensome.  This is a careful balance which will require care to
> maintain moving forward.

[bug#74736] [PATCH v10] Add Guix Consensus Document process

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Hi,

I sent v9 (Message-ID: 8734hiskwm.fsf@gmail.com) but that has not
reached the list, hum?!  And Hartmut sent a diff as v9, hence v10.  :-)

Changes compared to v8:

 • Changed some level for the subtitles.  And added “Getting Started”.
 
 • Removed trailing dot after repository URL.

 • Reworded ’prospective’.

 • Removed redundant information about “submitted” and pointed to the
   dedicated section.  Clarified using the term “draft”.

 • Replaced the term RFC by GCD.

 • Added a sentence about the role of “Sponsor”.  And added a
   “Contributor” role.  The idea is to rely on that term for clarifying
   “author” and who can discuss.  But then, the term does not appear…

 • Add section “Channel of Communication”.

 • Revamped the artist view of the timeline.

 • Minor tweaks under “Submission Period”.

 • Minor tweaks under “Discussion Period”.  Added a paragraph to deal
   with the case where “Author” and “Sponsor” vanish.

 • Minor tweaks under “Deliberation Period”: moved sentence; removed
   redundant information.

 • Minor tweaks under “Merging GCD”.


WDYT?

Cheers,
simon

--

[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 9703 bytes --]

diff -u /tmp/001-gcd-process-v8.md /tmp/001-gcd-process-v10.md
--- /tmp/001-gcd-process-v8.md	2025-01-17 01:21:27.574454166 +0100
+++ /tmp/001-gcd-process-v10.md	2025-01-17 01:36:03.524561874 +0100
@@ -70,37 +70,39 @@
 These day-to-day contributions remain governed by the process described
 by the manual in its “Contributing” chapter.

-## How the Process Works
+# How the Process Works
+
+## Getting Started

 1. Clone
-   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
+   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
    is a short descriptive name and `XYZ` is the sequence number.
-3. Write your GCD following the template’s structure.  The GCD 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
+3. Write your GCD following the template’s structure.  The GCD must
+   describe a concrete idea and sketch a plan to implement it, even
+   if not all details are known; the GCD must not be a brainstorming
+   session or a vague idea but a concrete proposal.  If it intends to
    deprecate a previously-accepted GCD, it must explicitly say so.
 4. Submit the GCD as a patch to `guix-patches@gnu.org`.
 5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
    one or more people who will support the GCD and participate in
    discussions by your side (see below).

-The GCD is *submitted* once it has at least one sponsor in addition to
-the author(s).  See “Submission Period” below.
-
-Submitted GCD is announced at `info-guix@gnu.org`.
+The GCD is now in “draft” state and will be *submitted* once it has at least
+one sponsor in addition to the author(s).  See “Submission Period” below.

 ## Roles

-  - An *author* is the person or one of the persons submitting the RFC.
+  - An *author* is the person or one of the persons submitting the GCD.
     Authors bear the responsibility to carry out the process to its
     conclusion.

   - A *sponsor* is a contributor who, during the submission period (see
     below), informs the author(s) that they would like to support the
-    RFC by participating in discussions, providing constructive comments
+    GCD by participating in discussions, providing constructive comments
     to help the author(s), soliciting opinions, and acting as
-    timekeepers.
+    timekeepers.  As a sponsor, please make sure that all have the time
+    and space for expressing their comments.

     Sponsors should be contributors who consider being sufficiently
     familiar with the project’s practices; hence it is recommended, but
@@ -111,6 +113,20 @@
     members is maintained in the file `etc/teams.scm` in the Guix
     repository.

+  - A *contributor* is a person contributing to Guix either with code,
+    translation, reviewing, etc. and more broadly any person feeling part
+    of the Guix community.
+
+## Channels of Communication
+
+ - The *draft* is sent to `guix-devel@gnu.org`.
+
+ - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
+   using the assigned issue number.
+
+ - The *final* document is published to `info-guix@gnu.org` and the
+   deliberating replies are sent to the assigned issue number.
+
 ## Timeline

 A GCD must follow the process illustrated by the diagram below,
@@ -118,49 +134,60 @@


 ```
-                         +-----------+
-          +- - - - - - ->| Withdrawn |<----------------------+
-          :              +-----------+                       |
-          :                    ^                             |
-          :                    :                             |
-+--------------------+   +---------------------+   +---------------------+
-| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
-|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
-+--------------------+   +---------------------+   +---------------------+
-                                                             |
-                                                             |
+       draft                    submitted                   final
++--------------------+    +---------------------+   +---------------------+
+| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
+|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
++--------------------+ :  +---------------------+   +---------------------+
+          :            :           :                         |
+          :            v           :                         |
+          :         canceled       v                         |
+          :                  o-----------o                   |
+          +- - - - - - - - ->| Withdrawn |<----------------- X
+                             o-----------o                   |
                                                              V
-                                                       +----------+
-                                                       | Accepted |
-                                                       +----------+
+                                                        o----------o
+                                                        | Accepted |
+                                                        o----------o
 ```

 The subsections below detail the various periods and their duration.

 ### Submission Period (up to 7 days)

-Anyone can author and submit a GCD as a regular patch and look for
-sponsors (see below).  The GCD is *submitted* once one or more people
+Anyone can author and propose a GCD as a regular patch and look for
+sponsors (see “Roles”).  The GCD is *submitted* once one or more people
 have volunteered to be sponsors by publicly replying “I sponsor”; it is
-canceled if no sponsor could be found during that period.  The next step
+*canceled* if no sponsor could be found during that period.  The next step
 is the *discussion period*.

 Authors may withdraw their GCD at any time; they can resubmit it again
-later, possibly under a new GCD number.
+later (under a new GCD number).

 ### Discussion Period (at least 30 days, up to 60 days)

-Once submitted, the GCD is publicly discussed; authors are encouraged to
-publish updated versions incorporating feedback during the discussion.
+Once submitted, the GCD is publicly discussed by all the members of the
+community.  Authors are encouraged to publish updated versions
+incorporating feedback during the discussion; members are encouraged to
+share a summary of their main concerns or opposition, if any, for being
+included under section “Open Issues” in the document.

 When deemed appropriate, between 30 days and 60 days after the start
 of the discussion period, the author(s) may publish a final version and
 announce the start of the *deliberation period*.

+If after 60 days, a final version is not yet published, then a grace period
+of 14 days is granted.  Finally the GCD is considered as *stale* and the last
+update is picked for the final version.
+
 ### Deliberation Period (14 days)

-All team members can participate in deliberation and are encouraged to
-do so.
+Deliberation aims at consolidating consensus; see “Decision Making”
+below.
+
+The *deliberation period* starts when the authors publish a final version of
+the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
+deliberating member and is encouraged to contribute to the deliberation.

 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 GCD:
@@ -172,16 +199,9 @@
   proposal.  A team member sending this reply should have made
   constructive comments during the discussion period.

-The GCD is *accepted* if (1) at least 25% of all team members send a
-reply, and (2) no one disapproves.  In other cases, the GCD is
-*withdrawn*.
-
-Deliberation aims at consolidating consensus; see “Decision Making”
-below.
-
-Anyone who is a team member is a deliberating member and is encouraged
-to contribute to the deliberation.  Team members are defined by the
-file etc/teams.scm (see “Teams” in the manual).
+The GCD is *accepted* if (1) at least 25% of all team members–as of
+the start of the “Deliberation Period”–send a reply, and (2) no one
+disapproves.  In other cases, the GCD is *withdrawn*.

 GCD acceptance is not a rubber stamp; in particular, it does not mean
 the proposal will effectively be implemented, but it does mean that all
@@ -206,16 +226,16 @@
 details, you are encouraged to read
 <https://www.seedsforchange.org.uk/consensus>.

-## Merging Final GCDs
+## Merging GCD

-Whether it is accepted or withdrawn, a committer merges the final GCD
-following these steps:
+Whether it is accepted or withdrawn, a person who has commit permission
+to the GCD repository merges the GCD following these steps:

 1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
-   `status` header accordingly);
+   `status` header accordingly with `deprecated`);
 2. committing everything;
 3. announcing the publication of the GCD.


Diff finished.  Fri Jan 17 01:36:38 2025

[-- Attachment #3: Type: text/plain, Size: 5 bytes --]



--

[-- Attachment #4: 001-gcd-process-v10.md --]
[-- Type: text/markdown, Size: 11964 bytes --]

title: Guix Consensus Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsors: pukkamustard, Ricardo Wurmus
date-submitted: 2024-12-12
date: 2025-01-15
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Consensus Document_ (GCD) process of the
Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
GCD first.

Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.

# How the Process Works

## Getting Started

1. Clone
   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
   is a short descriptive name and `XYZ` is the sequence number.
3. Write your GCD following the template’s structure.  The GCD must 
   describe a concrete idea and sketch a plan to implement it, even 
   if not all details are known; the GCD must not be a brainstorming
   session or a vague idea but a concrete proposal.  If it intends to
   deprecate a previously-accepted GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
   one or more people who will support the GCD and participate in
   discussions by your side (see below).

The GCD is now in “draft” state and will be *submitted* once it has at least
one sponsor in addition to the author(s).  See “Submission Period” below.

## Roles

  - An *author* is the person or one of the persons submitting the GCD.
    Authors bear the responsibility to carry out the process to its
    conclusion.

  - A *sponsor* is a contributor who, during the submission period (see
    below), informs the author(s) that they would like to support the
    GCD by participating in discussions, providing constructive comments
    to help the author(s), soliciting opinions, and acting as
    timekeepers.  As a sponsor, please make sure that all have the time
    and space for expressing their comments.

    Sponsors should be contributors who consider being sufficiently
    familiar with the project’s practices; hence it is recommended, but
    not mandatory, to be a team member.

  - A *team member* is the member of a team, as defined by the Guix
    project in the manual.  Currently, the list of teams and their
    members is maintained in the file `etc/teams.scm` in the Guix
    repository.

  - A *contributor* is a person contributing to Guix either with code,
    translation, reviewing, etc. and more broadly any person feeling part
    of the Guix community.

## Channels of Communication

 - The *draft* is sent to `guix-devel@gnu.org`.
 
 - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
   using the assigned issue number.
   
 - The *final* document is published to `info-guix@gnu.org` and the
   deliberating replies are sent to the assigned issue number.

## Timeline

A GCD must follow the process illustrated by the diagram below,
consisting of several *periods*.


```
       draft                    submitted                   final
+--------------------+    +---------------------+   +---------------------+
| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
+--------------------+ :  +---------------------+   +---------------------+
          :            :           :                         |
          :            v           :                         |
          :         canceled       v                         |
          :                  o-----------o                   |
          +- - - - - - - - ->| Withdrawn |<----------------- X
                             o-----------o                   |
                                                             V
                                                        o----------o
                                                        | Accepted |
                                                        o----------o
```

The subsections below detail the various periods and their duration.

### Submission Period (up to 7 days)

Anyone can author and propose a GCD as a regular patch and look for
sponsors (see “Roles”).  The GCD is *submitted* once one or more people
have volunteered to be sponsors by publicly replying “I sponsor”; it is
*canceled* if no sponsor could be found during that period.  The next step
is the *discussion period*.

Authors may withdraw their GCD at any time; they can resubmit it again
later (under a new GCD number).

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD is publicly discussed by all the members of the
community.  Authors are encouraged to publish updated versions
incorporating feedback during the discussion; members are encouraged to
share a summary of their main concerns or opposition, if any, for being
included under section “Open Issues” in the document.

When deemed appropriate, between 30 days and 60 days after the start
of the discussion period, the author(s) may publish a final version and
announce the start of the *deliberation period*.

If after 60 days, a final version is not yet published, then a grace period
of 14 days is granted.  Finally the GCD is considered as *stale* and the last 
update is picked for the final version.

### Deliberation Period (14 days)

Deliberation aims at consolidating consensus; see “Decision Making”
below.

The *deliberation period* starts when the authors publish a final version of
the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
deliberating member and is encouraged to contribute to the deliberation.

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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply should have made
  constructive comments during the discussion period.

The GCD is *accepted* if (1) at least 25% of all team members–as of 
the start of the “Deliberation Period”–send a reply, and (2) no one 
disapproves.  In other cases, the GCD is *withdrawn*.

GCD 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 GCD 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 GCD

Whether it is accepted or withdrawn, a person who has commit permission 
to the GCD repository merges the GCD following these steps:

1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
   `status` header accordingly with `deprecated`);
2. committing everything;
3. announcing the publication of the GCD.

All the GCDs 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) or (at your option)
any later version.

## GCD Template

The expected structure of GCDs is captured by the template in the file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

The GCD process described in this document can be amended by subsequent
GCDs.

## 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.

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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

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

[Maxim Cournoyer]

Hi Simon and others!

Thanks for the good work.  I've been struggling keeping pace with it, ah!

I liked it already a year ago, and I like it more now, thanks to the
various refinements brought to it in this thread.  Below are small typos
I've spotted and other suggestions.

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> title: Guix Consensus Document Process
> id: 001
> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> sponsors: pukkamustard, Ricardo Wurmus
> date-submitted: 2024-12-12
> date: 2025-01-15
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---
>
> # Summary
>
> This document describes the _Guix Consensus Document_ (GCD) process of the
> Guix project.  The GCD process is intended to provide a consistent and

GNU Guix project, later referenced as either Guix or "the project", for
brevity.

> structured way to propose, discuss, and decide on major changes
> affecting the project.  It aims to draw attention of community members

the attention

> 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 GCD process is a mechanism to determine whether a proposed change is
> “significant” enough to require attention from the community at large

Why quote "significant" ?

> 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 “significant” when it could only be reverted at a

Ditto.

> high cost or, for technical changes, when it has 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 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.).

Punctuaction rule: I seem to recall that you don't need a trailing dot
if there is already one, even inside a preceding closing parens [0].

[0]  https://english.stackexchange.com/a/8385

> # Detailed Design
>
> ## When to Follow This Process
>
> The GCD process applies only to “significant” changes, which include:

The quotes here, again.

> - 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
> GCD first.
>
> Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.

in the ["Contributing" section of the GNU Guix Reference
Manual](https://guix.gnu.org/manual/devel/en/html_node/Contributing.html).

> # How the Process Works
>
> ## Getting Started
>
> 1. Clone
>    https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
> 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
>    is a short descriptive name and `XYZ` is the sequence number.
> 3. Write your GCD following the template’s structure.  The GCD must

I'd use just 'template structure', without 's

>    describe a concrete idea and sketch a plan to implement it, even
>    if not all details are known; the GCD must not be a brainstorming
>    session or a vague idea but a concrete proposal.  If it intends to
>    deprecate a previously-accepted GCD, it must explicitly say so.
> 4. Submit the GCD as a patch to `guix-patches@gnu.org`.
> 5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
>    one or more people who will support the GCD and participate in
>    discussions by your side (see below).
>
> The GCD is now in “draft” state and will be *submitted* once it has at least

Maybe use *draft* instead of quotes, for emphasis, if deemed necessary.

> one sponsor in addition to the author(s).  See “Submission Period” below.

Markdown (or at least most flavors in use of it) supports referring to
sections via URL, IIRC.  So I'd use:

--8<---------------cut here---------------start------------->8---
See [Submission Period](#submission-period) below.
--8<---------------cut here---------------end--------------->8---

Taking care to add the #submission-period custom id if our parser
doesn't do so automatically. [1]

[1]  https://www.markdownguide.org/extended-syntax/#heading-ids

>
> ## Roles
>
>   - An *author* is the person or one of the persons submitting the GCD.
>     Authors bear the responsibility to carry out the process to its
>     conclusion.
>
>   - A *sponsor* is a contributor who, during the submission period (see
>     below), informs the author(s) that they would like to support the
>     GCD by participating in discussions, providing constructive comments
>     to help the author(s), soliciting opinions, and acting as
>     timekeepers.  As a sponsor, please make sure that all have the time

all *participants*

>     and space for expressing their comments.
>
>     Sponsors should be contributors who consider being sufficiently
>     familiar with the project’s practices; hence it is recommended, but
>     not mandatory, to be a team member.
>
>   - A *team member* is the member of a team, as defined by the Guix
>     project in the manual.  Currently, the list of teams and their

as defined in the [Teams section of the GNU Guix Reference Manual](https://guix.gnu.org/manual/devel/en/html_node/Teams.html).

>     members is maintained in the file `etc/teams.scm` in the Guix
>     repository.

[GNU Guix repository](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/teams.scm)
>
>   - A *contributor* is a person contributing to Guix either with code,
>     translation, reviewing, etc. and more broadly any person feeling part
>     of the Guix community.
>
> ## Channels of Communication
>
>  - The *draft* is sent to `guix-devel@gnu.org`.
>
>  - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
>    using the assigned issue number.
>
>  - The *final* document is published to `info-guix@gnu.org` and the
>    deliberating replies are sent to the assigned issue number.
>
> ## Timeline
>
> A GCD must follow the process illustrated by the diagram below,
> consisting of several *periods*.
>
>
> ```
>        draft                    submitted                   final
> +--------------------+    +---------------------+   +---------------------+
> | Submission Period  |    |  Discussion Period  |   | Deliberation Period |
> |  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
> +--------------------+ :  +---------------------+   +---------------------+
>           :            :           :                         |
>           :            v           :                         |
>           :         canceled       v                         |

s/canceled/cancelled/

>           :                  o-----------o                   |
>           +- - - - - - - - ->| Withdrawn |<----------------- X
>                              o-----------o                   |
>                                                              V
>                                                         o----------o
>                                                         | Accepted |
>                                                         o----------o
> ```
>
> The subsections below detail the various periods and their duration.
>
> ### Submission Period (up to 7 days)
>
> Anyone can author and propose a GCD as a regular patch and look for
> sponsors (see “Roles”).  The GCD is *submitted* once one or more people
> have volunteered to be sponsors by publicly replying “I sponsor”; it is
> *canceled* if no sponsor could be found during that period.  The next step

s/canceled/cancelled/

> is the *discussion period*.
>
> Authors may withdraw their GCD at any time; they can resubmit it again
> later (under a new GCD number).
>
> ### Discussion Period (at least 30 days, up to 60 days)
>
> Once submitted, the GCD is publicly discussed by all the members of the
> community.  Authors are encouraged to publish updated versions
> incorporating feedback during the discussion; members are encouraged to
> share a summary of their main concerns or opposition, if any, for being
> included under section “Open Issues” in the document.
>
> When deemed appropriate, between 30 days and 60 days after the start
> of the discussion period, the author(s) may publish a final version and
> announce the start of the *deliberation period*.
>
> If after 60 days, a final version is not yet published, then a grace period
> of 14 days is granted.  Finally the GCD is considered as *stale* and the last
> update is picked for the final version.
>
> ### Deliberation Period (14 days)
>
> Deliberation aims at consolidating consensus; see “Decision Making”
> below.
>
> The *deliberation period* starts when the authors publish a final version of
> the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
> deliberating member and is encouraged to contribute to the deliberation.
>
> 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 GCD:
>
> - “I support”, meaning that one supports the proposal;
> - “I accept”, meaning that one consents to the implementation of the
>   proposal;
> - “I disapprove”, meaning that one opposes the implementation of the
>   proposal.  A team member sending this reply should have made
>   constructive comments during the discussion period.
>
> The GCD is *accepted* if (1) at least 25% of all team members–as of
> the start of the “Deliberation Period”–send a reply, and (2) no one
> disapproves.  In other cases, the GCD is *withdrawn*.
>
> GCD 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 GCD 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 GCD
>
> Whether it is accepted or withdrawn, a person who has commit permission
> to the GCD repository merges the GCD following these steps:
>
> 1. filling in the remaining metadata in the GCD headers (changing the
>    `status` to `accepted` or `withdrawn`; adding the URL of the

Instead of ing form, I'd just use imperative for these steps, which is
more concise and in line with how we document code already.

s/filling/fill/

>    discussion in the `discussion` header; updating the `date` header; if
>    previously-accepted GCDs are deprecated by this new GCD, change the
>    `status` header accordingly with `deprecated`);
> 2. committing everything;

s/committing/Commit an push the resulting document/

> 3. announcing the publication of the GCD.

s/announcing/announce/

> All the GCDs 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) or (at your option)
> any later version.
>
> ## GCD Template
>
> The expected structure of GCDs is captured by the template in the file

by the template file

> `000-template.md`, written in English with Markdown syntax.
>
> ## Cost of Reverting
>
> The GCD process described in this document can be amended by subsequent
> GCDs.

This section name (Cost of Reverting) doesn't match with its content?

> ## Drawbacks
>
> There is a risk that the additional process will hinder contribution more than
> it would help.

may hinder or burden contributions, potentially causing more harm than
good.

> 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

s/over-/over/ ?

> and notably avoid repeating arguments, avoid using exclusionary jargon,
> and solicit opinions of those who remained silent.

s/of those/from those/

> ## 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

s/that affect users/affecting users/

> well-considered, we certainly don’t want the process to become unduly
> burdensome.  This is a careful balance which will require care to

s/careful/delicate/, to avoid repeating 'care' twice.

Assuming my above comments are addressed,

Reviewed-by: Maxim Cournoyer <maxim.cournoyer@gmail>

-- 
Thanks,
Maxim

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

[Ludovic Courtès]

Hello,

Just one note:

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>> The GCD process is a mechanism to determine whether a proposed change is
>> “significant” enough to require attention from the community at large
>
> Why quote "significant" ?

To me, this is to emphasize that what is meant by “significant” will be
clarified below.

(Thanks for all the other comments and suggestions!)

Ludo’.

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

[Maxim Cournoyer]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Just one note:
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> The GCD process is a mechanism to determine whether a proposed change is
>>> “significant” enough to require attention from the community at large
>>
>> Why quote "significant" ?
>
> To me, this is to emphasize that what is meant by “significant” will be
> clarified below.

OK.  That wasn't clear to me.  I'd suggest wording that explicitly, for
example:

--8<---------------cut here---------------start------------->8---
[...] a proposed change is "significant" (which meaning is clarified
below)
--8<---------------cut here---------------end--------------->8---

or similar.

> (Thanks for all the other comments and suggestions!)

My pleasure!

Happy 2025!

-- 
Thanks,
Maxim

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

[Simon Tournier]

Hi,

On Tue, 21 Jan 2025 at 08:47, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> To me, this is to emphasize that what is meant by “significant” will be
>> clarified below.
>
> OK.  That wasn't clear to me.  I'd suggest wording that explicitly, for
> example:
>
> --8<---------------cut here---------------start------------->8---
> [...] a proposed change is "significant" (which meaning is clarified
> below)
> --8<---------------cut here---------------end--------------->8---
>
> or similar.

I emphasized with *significant* because it’s consistent with the rest
(*draft*, *submitted*, *periods*, etc.).

Cheers,
simon

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

[Simon Tournier]

Hi Maxim,

Thanks for your comments.  All included except one.

On Mon, 20 Jan 2025 at 11:50, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> - changing the contributor workflow and related infrastructure (mailing
>>   lists, source code repository and forge, continuous integration, etc.).
>
> Punctuaction rule: I seem to recall that you don't need a trailing dot
> if there is already one, even inside a preceding closing parens [0].
>
> [0]  https://english.stackexchange.com/a/8385

Hum, I think here etc. does not act as the last term of the sentence
because it’s inside the parenthesis.  It does not appear to me a
double-duty case.

Anyway, in doubt I replaced by ’and so on’. :-)


>> The GCD process applies only to “significant” changes, which include:
>
> The quotes here, again.

Replaced by *significant*, thus it’s consistent with the rest.

>> one sponsor in addition to the author(s).  See “Submission Period” below.
>
> Markdown (or at least most flavors in use of it) supports referring to
> sections via URL, IIRC.  So I'd use:
>
> --8<---------------cut here---------------start------------->8---
> See [Submission Period](#submission-period) below.
> --8<---------------cut here---------------end--------------->8---

Since it makes the document in plain text harder to read and it does not
bring much, and we do not know yet how these GCDs will be parsed, it
appears to me simpler to keep it that way, for now.


>> ## Cost of Reverting
>>
>> The GCD process described in this document can be amended by subsequent
>> GCDs.
>
> This section name (Cost of Reverting) doesn't match with its content?

I added “Not applicable” because it’s hard to predict the cost of
reverting about something that we have never tried. :-)


Cheers,
simon

[bug#74736] [PATCH v10] Add Guix Consensus Document process

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Hi,

I sent v9 (Message-ID: 8734hiskwm.fsf@gmail.com) but that has not
reached the list, hum?!  And Hartmut sent a diff as v9, hence v10.  :-)

Changes compared to v8:

 • Changed some level for the subtitles.  And added “Getting Started”.
 
 • Removed trailing dot after repository URL.

 • Reworded ’prospective’.

 • Removed redundant information about “submitted” and pointed to the
   dedicated section.  Clarified using the term “draft”.

 • Replaced the term RFC by GCD.

 • Added a sentence about the role of “Sponsor”.  And added a
   “Contributor” role.  The idea is to rely on that term for clarifying
   “author” and who can discuss.  But then, the term does not appear…

 • Add section “Channel of Communication”.

 • Revamped the artist view of the timeline.

 • Minor tweaks under “Submission Period”.

 • Minor tweaks under “Discussion Period”.  Added a paragraph to deal
   with the case where “Author” and “Sponsor” vanish.

 • Minor tweaks under “Deliberation Period”: moved sentence; removed
   redundant information.

 • Minor tweaks under “Merging GCD”.


WDYT?

Cheers,
simon

--

[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 9703 bytes --]

diff -u /tmp/001-gcd-process-v8.md /tmp/001-gcd-process-v10.md
--- /tmp/001-gcd-process-v8.md	2025-01-17 01:21:27.574454166 +0100
+++ /tmp/001-gcd-process-v10.md	2025-01-17 01:36:03.524561874 +0100
@@ -70,37 +70,39 @@
 These day-to-day contributions remain governed by the process described
 by the manual in its “Contributing” chapter.

-## How the Process Works
+# How the Process Works
+
+## Getting Started

 1. Clone
-   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git .
+   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
 2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
    is a short descriptive name and `XYZ` is the sequence number.
-3. Write your GCD following the template’s structure.  The GCD 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
+3. Write your GCD following the template’s structure.  The GCD must
+   describe a concrete idea and sketch a plan to implement it, even
+   if not all details are known; the GCD must not be a brainstorming
+   session or a vague idea but a concrete proposal.  If it intends to
    deprecate a previously-accepted GCD, it must explicitly say so.
 4. Submit the GCD as a patch to `guix-patches@gnu.org`.
 5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
    one or more people who will support the GCD and participate in
    discussions by your side (see below).

-The GCD is *submitted* once it has at least one sponsor in addition to
-the author(s).  See “Submission Period” below.
-
-Submitted GCD is announced at `info-guix@gnu.org`.
+The GCD is now in “draft” state and will be *submitted* once it has at least
+one sponsor in addition to the author(s).  See “Submission Period” below.

 ## Roles

-  - An *author* is the person or one of the persons submitting the RFC.
+  - An *author* is the person or one of the persons submitting the GCD.
     Authors bear the responsibility to carry out the process to its
     conclusion.

   - A *sponsor* is a contributor who, during the submission period (see
     below), informs the author(s) that they would like to support the
-    RFC by participating in discussions, providing constructive comments
+    GCD by participating in discussions, providing constructive comments
     to help the author(s), soliciting opinions, and acting as
-    timekeepers.
+    timekeepers.  As a sponsor, please make sure that all have the time
+    and space for expressing their comments.

     Sponsors should be contributors who consider being sufficiently
     familiar with the project’s practices; hence it is recommended, but
@@ -111,6 +113,20 @@
     members is maintained in the file `etc/teams.scm` in the Guix
     repository.

+  - A *contributor* is a person contributing to Guix either with code,
+    translation, reviewing, etc. and more broadly any person feeling part
+    of the Guix community.
+
+## Channels of Communication
+
+ - The *draft* is sent to `guix-devel@gnu.org`.
+
+ - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
+   using the assigned issue number.
+
+ - The *final* document is published to `info-guix@gnu.org` and the
+   deliberating replies are sent to the assigned issue number.
+
 ## Timeline

 A GCD must follow the process illustrated by the diagram below,
@@ -118,49 +134,60 @@


 ```
-                         +-----------+
-          +- - - - - - ->| Withdrawn |<----------------------+
-          :              +-----------+                       |
-          :                    ^                             |
-          :                    :                             |
-+--------------------+   +---------------------+   +---------------------+
-| Submission Period	 |   |  Discussion Period  |   | Deliberation Period |
-|  (up to 7 days)    |-->|   (30–60 days)      |-->|     (14 days)		 |
-+--------------------+   +---------------------+   +---------------------+
-                                                             |
-                                                             |
+       draft                    submitted                   final
++--------------------+    +---------------------+   +---------------------+
+| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
+|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
++--------------------+ :  +---------------------+   +---------------------+
+          :            :           :                         |
+          :            v           :                         |
+          :         canceled       v                         |
+          :                  o-----------o                   |
+          +- - - - - - - - ->| Withdrawn |<----------------- X
+                             o-----------o                   |
                                                              V
-                                                       +----------+
-                                                       | Accepted |
-                                                       +----------+
+                                                        o----------o
+                                                        | Accepted |
+                                                        o----------o
 ```

 The subsections below detail the various periods and their duration.

 ### Submission Period (up to 7 days)

-Anyone can author and submit a GCD as a regular patch and look for
-sponsors (see below).  The GCD is *submitted* once one or more people
+Anyone can author and propose a GCD as a regular patch and look for
+sponsors (see “Roles”).  The GCD is *submitted* once one or more people
 have volunteered to be sponsors by publicly replying “I sponsor”; it is
-canceled if no sponsor could be found during that period.  The next step
+*canceled* if no sponsor could be found during that period.  The next step
 is the *discussion period*.

 Authors may withdraw their GCD at any time; they can resubmit it again
-later, possibly under a new GCD number.
+later (under a new GCD number).

 ### Discussion Period (at least 30 days, up to 60 days)

-Once submitted, the GCD is publicly discussed; authors are encouraged to
-publish updated versions incorporating feedback during the discussion.
+Once submitted, the GCD is publicly discussed by all the members of the
+community.  Authors are encouraged to publish updated versions
+incorporating feedback during the discussion; members are encouraged to
+share a summary of their main concerns or opposition, if any, for being
+included under section “Open Issues” in the document.

 When deemed appropriate, between 30 days and 60 days after the start
 of the discussion period, the author(s) may publish a final version and
 announce the start of the *deliberation period*.

+If after 60 days, a final version is not yet published, then a grace period
+of 14 days is granted.  Finally the GCD is considered as *stale* and the last
+update is picked for the final version.
+
 ### Deliberation Period (14 days)

-All team members can participate in deliberation and are encouraged to
-do so.
+Deliberation aims at consolidating consensus; see “Decision Making”
+below.
+
+The *deliberation period* starts when the authors publish a final version of
+the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
+deliberating member and is encouraged to contribute to the deliberation.

 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 GCD:
@@ -172,16 +199,9 @@
   proposal.  A team member sending this reply should have made
   constructive comments during the discussion period.

-The GCD is *accepted* if (1) at least 25% of all team members send a
-reply, and (2) no one disapproves.  In other cases, the GCD is
-*withdrawn*.
-
-Deliberation aims at consolidating consensus; see “Decision Making”
-below.
-
-Anyone who is a team member is a deliberating member and is encouraged
-to contribute to the deliberation.  Team members are defined by the
-file etc/teams.scm (see “Teams” in the manual).
+The GCD is *accepted* if (1) at least 25% of all team members–as of
+the start of the “Deliberation Period”–send a reply, and (2) no one
+disapproves.  In other cases, the GCD is *withdrawn*.

 GCD acceptance is not a rubber stamp; in particular, it does not mean
 the proposal will effectively be implemented, but it does mean that all
@@ -206,16 +226,16 @@
 details, you are encouraged to read
 <https://www.seedsforchange.org.uk/consensus>.

-## Merging Final GCDs
+## Merging GCD

-Whether it is accepted or withdrawn, a committer merges the final GCD
-following these steps:
+Whether it is accepted or withdrawn, a person who has commit permission
+to the GCD repository merges the GCD following these steps:

 1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
-   `status` header accordingly);
+   `status` header accordingly with `deprecated`);
 2. committing everything;
 3. announcing the publication of the GCD.


Diff finished.  Fri Jan 17 01:36:38 2025

[-- Attachment #3: Type: text/plain, Size: 5 bytes --]



--

[-- Attachment #4: 001-gcd-process-v10.md --]
[-- Type: text/markdown, Size: 11964 bytes --]

title: Guix Consensus Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsors: pukkamustard, Ricardo Wurmus
date-submitted: 2024-12-12
date: 2025-01-15
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Consensus Document_ (GCD) process of the
Guix project.  The GCD 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 GCD process is a mechanism to determine whether a proposed change is
“significant” enough to require attention from the community 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 “significant” 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 `<package>` 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 GCD process applies only to “significant” changes, which 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
GCD first.

Most day-to-day contributions do *not* require a GCD; 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 “Contributing” chapter.

# How the Process Works

## Getting Started

1. Clone
   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name`
   is a short descriptive name and `XYZ` is the sequence number.
3. Write your GCD following the template’s structure.  The GCD must 
   describe a concrete idea and sketch a plan to implement it, even 
   if not all details are known; the GCD must not be a brainstorming
   session or a vague idea but a concrete proposal.  If it intends to
   deprecate a previously-accepted GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*:
   one or more people who will support the GCD and participate in
   discussions by your side (see below).

The GCD is now in “draft” state and will be *submitted* once it has at least
one sponsor in addition to the author(s).  See “Submission Period” below.

## Roles

  - An *author* is the person or one of the persons submitting the GCD.
    Authors bear the responsibility to carry out the process to its
    conclusion.

  - A *sponsor* is a contributor who, during the submission period (see
    below), informs the author(s) that they would like to support the
    GCD by participating in discussions, providing constructive comments
    to help the author(s), soliciting opinions, and acting as
    timekeepers.  As a sponsor, please make sure that all have the time
    and space for expressing their comments.

    Sponsors should be contributors who consider being sufficiently
    familiar with the project’s practices; hence it is recommended, but
    not mandatory, to be a team member.

  - A *team member* is the member of a team, as defined by the Guix
    project in the manual.  Currently, the list of teams and their
    members is maintained in the file `etc/teams.scm` in the Guix
    repository.

  - A *contributor* is a person contributing to Guix either with code,
    translation, reviewing, etc. and more broadly any person feeling part
    of the Guix community.

## Channels of Communication

 - The *draft* is sent to `guix-devel@gnu.org`.
 
 - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
   using the assigned issue number.
   
 - The *final* document is published to `info-guix@gnu.org` and the
   deliberating replies are sent to the assigned issue number.

## Timeline

A GCD must follow the process illustrated by the diagram below,
consisting of several *periods*.


```
       draft                    submitted                   final
+--------------------+    +---------------------+   +---------------------+
| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
+--------------------+ :  +---------------------+   +---------------------+
          :            :           :                         |
          :            v           :                         |
          :         canceled       v                         |
          :                  o-----------o                   |
          +- - - - - - - - ->| Withdrawn |<----------------- X
                             o-----------o                   |
                                                             V
                                                        o----------o
                                                        | Accepted |
                                                        o----------o
```

The subsections below detail the various periods and their duration.

### Submission Period (up to 7 days)

Anyone can author and propose a GCD as a regular patch and look for
sponsors (see “Roles”).  The GCD is *submitted* once one or more people
have volunteered to be sponsors by publicly replying “I sponsor”; it is
*canceled* if no sponsor could be found during that period.  The next step
is the *discussion period*.

Authors may withdraw their GCD at any time; they can resubmit it again
later (under a new GCD number).

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD is publicly discussed by all the members of the
community.  Authors are encouraged to publish updated versions
incorporating feedback during the discussion; members are encouraged to
share a summary of their main concerns or opposition, if any, for being
included under section “Open Issues” in the document.

When deemed appropriate, between 30 days and 60 days after the start
of the discussion period, the author(s) may publish a final version and
announce the start of the *deliberation period*.

If after 60 days, a final version is not yet published, then a grace period
of 14 days is granted.  Finally the GCD is considered as *stale* and the last 
update is picked for the final version.

### Deliberation Period (14 days)

Deliberation aims at consolidating consensus; see “Decision Making”
below.

The *deliberation period* starts when the authors publish a final version of
the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
deliberating member and is encouraged to contribute to the deliberation.

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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply should have made
  constructive comments during the discussion period.

The GCD is *accepted* if (1) at least 25% of all team members–as of 
the start of the “Deliberation Period”–send a reply, and (2) no one 
disapproves.  In other cases, the GCD is *withdrawn*.

GCD 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 GCD 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 GCD

Whether it is accepted or withdrawn, a person who has commit permission 
to the GCD repository merges the GCD following these steps:

1. filling in the remaining metadata in the GCD 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 GCDs are deprecated by this new GCD, change the
   `status` header accordingly with `deprecated`);
2. committing everything;
3. announcing the publication of the GCD.

All the GCDs 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) or (at your option)
any later version.

## GCD Template

The expected structure of GCDs is captured by the template in the file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

The GCD process described in this document can be amended by subsequent
GCDs.

## 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.

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’t want the process to become unduly
burdensome.  This is a careful balance which will require care to
maintain moving forward.

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

[Ludovic Courtès]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> I sent v9 (Message-ID: 8734hiskwm.fsf@gmail.com) but that has not
> reached the list, hum?!  And Hartmut sent a diff as v9, hence v10.  :-)

Thanks for sending v10, late at night!

It’s of course not the only metric but there’s a bit of possibly
worrying inflation between v8 and v10:

 001-gcd-process-v10.md |  116 ++++++++++++++++++++++++++++---------------------
 1 file changed, 68 insertions(+), 48 deletions(-)

> +  - A *contributor* is a person contributing to Guix either with code,
> +    translation, reviewing, etc. and more broadly any person feeling part
> +    of the Guix community.

I would drop the last part, which makes it to fuzzy IMO:

  - A *contributor* is a person who has been participating in Guix
    activities, for instance by writing or reviewing code, by supporting
    users on fora, or by contributing to translations.

> +## Channels of Communication

Rather “Communication Channels”.

> + - The *draft* is sent to `guix-devel@gnu.org`.

s/sent/sent by email/

> +If after 60 days, a final version is not yet published, then a grace period
> +of 14 days is granted.  Finally the GCD is considered as *stale* and the last
> +update is picked for the final version.

This is like saying “between 30 and 74 days” in practice.

I would rather stick to the 60-day hard limit and clarify what happens
if author(s) fail to act during that time (starting with the paragraph
just above):

  When deemed appropriate, between 30 days and 60 days after the start
  of the discussion period, the author(s) may publish a final version
  and announce the start of the *deliberation period*.  If the authors
  fail to do so, the deliberation period automatically starts 60 days
  after the start of the discussion period based on the latest version
  provided by the author(s).

> -## Merging Final GCDs
> +## Merging GCD

“Merging GCDs”

> -Whether it is accepted or withdrawn, a committer merges the final GCD
> -following these steps:
> +Whether it is accepted or withdrawn, a person who has commit permission

“a person with commit rights”

I think it’s a good document at this point!

Ludo’.

[bug#74736] [FWD] Guix Consensus Document process – deliberation

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

Repost because “550 This message scored 18.0 spam points.”

-------------------- Start of forwarded message --------------------
From: Simon Tournier <zimon.toutoune@gmail.com>
To: info-guix@gnu.org, 74736@debbugs.gnu.org
Cc: [...]
    all teams members
  + all people with commit access  

Subject: Guix Consensus Document process – deliberation
Date: Wed, 22 Jan 2025 20:44:08 +0100


[-- Attachment #2.1: Type: text/plain, Size: 1164 bytes --]

Hi all,

Here is the Guix Consensus Document (GCD) process which implements how
we will collectively make decision on *significant* changes.  Since it
bootstraps the process, it’s important to have a common understanding of
it.

If you are member of a team (etc/teams.scm), you are asked to send by
email to 74736@debbugs.gnu.org your reply, either:

 • I support;
 • I accept;
 • I disapprove.

If you have commit access and not yet a member of any team, please
consider to join one.  Since we are bootstrapping the process, your
reply matters too. :-)

The Deliberation Period ends on February, 5th everywhere on Earth.

Note that the Discussion Period is now done.  Therefore, if you accept
with strong concerns, please provide a summary (5-10 lines) that will be
included in the final document.

If someone disapproves, please explicitly point which major comment you
did that had not been included in this final document.

Attached the GCD file and the template file. Below various milestones if
you need more context.

Thanks for all the comments!  I’m personally happy with this outcome. :-)

Cheers,
simon

--

[-- Attachment #2.2: 001-gcd-process.md --]
[-- Type: text/markdown, Size: 12279 bytes --]

title: Guix Consensus Document Process
id: 001
status: submitted
discussion: https://issues.guix.gnu.org/74736
authors: Simon Tournier, Noé Lopez, Ludovic Courtès
sponsors: pukkamustard, Ricardo Wurmus
date: 2025-12-08
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

This document describes the _Guix Consensus Document_ (GCD) process of the
GNU Guix project, later referenced as either Guix or “the project“, for
brevity.  The GCD 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 the 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 GCD process is a mechanism to determine whether a proposed change is
*significant* enough to require attention from the community 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 *significant* 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 `<package>` 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, and so
  on).

# Detailed Design

## When to Follow This Process

The GCD process applies only to *significant* changes, which 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
GCD first.

Most day-to-day contributions do *not* require a GCD; 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 in
the [”Contributing“ section of the GNU Guix Reference
Manual](https://guix.gnu.org/manual/devel/en/html_node/Contributing.html).

# How the Process Works

## Getting Started

1. Clone
   https://git.savannah.gnu.org/git/guix/guix-consensus-documents.git
2. Copy `000-template.md` to `XYZ-short-name.md` where `short-name` is a
   short descriptive name and `XYZ` is the sequence number.
3. Write your GCD following the template structure.  The GCD must describe
   a concrete idea and sketch a plan to implement it, even if not all
   details are known; the GCD must not be a brainstorming session or a
   vague idea but a concrete proposal.  If it intends to deprecate a
   previously-accepted GCD, it must explicitly say so.
4. Submit the GCD as a patch to `guix-patches@gnu.org`.
5. Announce your GCD at `guix-devel@gnu.org` and look for *sponsors*: one
   or more people who will support the GCD and participate in discussions
   by your side (see below).

The GCD is now in *draft* state and will be *submitted* once it has at
least one sponsor in addition to the author(s).  See “Submission Period”
below.

## Roles

  - An *author* is the person or one of the persons submitting the GCD.
    Authors bear the responsibility to carry out the process to its
    conclusion.

  - A *sponsor* is a contributor who, during the submission period (see
    below), informs the author(s) that they would like to support the GCD
    by participating in discussions, providing constructive comments to
    help the author(s), soliciting opinions, and acting as timekeepers.  As
    a sponsor, please make sure that all participants have the time and
    space for expressing their comments.

    Sponsors should be contributors who consider being sufficiently
    familiar with the project’s practices; hence it is recommended, but not
    mandatory, to be a team member.

  - A *team member* is the member of a team, as defined in the [Teams
    section of the GNU Guix Reference
    Manual](https://guix.gnu.org/manual/devel/en/html_node/Teams.html).
    Currently, the list of teams and their members is maintained in the
    file `etc/teams.scm` in the [GNU Guix
    repository](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/teams.scm)

  - A *contributor* is a person who has been participating in Guix
    activities, for instance by writing or reviewing code, by supporting
    users on fora, or by contributing to translations.

## Communication Channels

 - The *draft* is sent by email to `guix-devel@gnu.org`.
 
 - Once *submitted*, the GCD is announced to `info-guix@gnu.org` and discussed
   using the assigned issue number.
   
 - The *final* document is published to `info-guix@gnu.org` and the
   deliberating replies are sent to the assigned issue number.

## Timeline

A GCD must follow the process illustrated by the diagram below,
consisting of several *periods*.

```
       draft                    submitted                   final
+--------------------+    +---------------------+   +---------------------+
| Submission Period  |    |  Discussion Period  |   | Deliberation Period |
|  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
+--------------------+ :  +---------------------+   +---------------------+
          :            :           :                         |
          :            v           :                         |
          :         cancelled      v                         |
          :                  o-----------o                   |
          +- - - - - - - - ->| Withdrawn |<----------------- X
                             o-----------o                   |
                                                             V
                                                        o----------o
                                                        | Accepted |
                                                        o----------o
```

The subsections below detail the various periods and their duration.

### Submission Period (up to 7 days)

Anyone can author and propose a GCD as a regular patch and look for
sponsors (see “Roles”).  The GCD is *submitted* once one or more people
have volunteered to be sponsors by publicly replying “I sponsor”; it is
*cancelled* if no sponsor could be found during that period.  The next step
is the *discussion period*.

Authors may withdraw their GCD at any time; they can resubmit it again
later (under a new GCD number).

### Discussion Period (at least 30 days, up to 60 days)

Once submitted, the GCD is publicly discussed by all the members of the
community.  Authors are encouraged to publish updated versions
incorporating feedback during the discussion; members are encouraged to
share a summary of their main concerns or opposition, if any, for being
included under section “Open Issues” in the document.

When deemed appropriate, between 30 days and 60 days after the start of the
discussion period, the author(s) may publish a final version and announce
the start of the *deliberation period*.  If the authors fail to do so, the
deliberation period automatically starts 60 days after the start of the
discussion period based on the latest version provided by the author(s).

### Deliberation Period (14 days)

Deliberation aims at consolidating consensus; see “Decision Making” below.

The *deliberation period* starts when the authors publish a final version
of the GCD at `info-guix@gnu.org`.  Anyone who is a team member is a
deliberating member and is encouraged to contribute to the deliberation.

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 GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the
  proposal;
- “I disapprove”, meaning that one opposes the implementation of the
  proposal.  A team member sending this reply should have made constructive
  comments during the discussion period.

The GCD is *accepted* if (1) at least 25% of all team members–as of the
start of the “Deliberation Period”–send a reply, and (2) no one
disapproves.  In other cases, the GCD is *withdrawn*.

GCD 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 GCD 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 GCDs

Whether it is accepted or withdrawn, a person with commit rights merges the
GCD following these steps:

1. Fill in the remaining metadata in the GCD 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
   GCDs are deprecated by this new GCD, change the `status` header
   accordingly with `deprecated`);
2. Commit everything;
3. Announce the publication of the GCD.

All the GCDs 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)
or (at your option) any later version.

## GCD Template

The expected structure of GCDs is captured by the template file
`000-template.md`, written in English with Markdown syntax.

## Cost of Reverting

Not applicable.  Please note that the GCD process described in this
document can be amended by subsequent GCDs.

## Drawbacks

There is a risk that the additional process may hinder or burden
contributions, potentially causing more harm than good.  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 from 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 affecting users are
well-considered, we certainly don’t want the process to become unduly
burdensome.  This is a delicate balance which will require care to maintain
moving forward.

[-- Attachment #2.3: Type: text/plain, Size: 7 bytes --]

--

--

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.4: 000-template.md --]
[-- Type: text/markdown, Size: 2171 bytes --]

title: <Name Of The Proposal>
id: <the next available number>
status: <draft|submitted|accepted|withdrawn|deprecated>
discussion: https://issues.guix.gnu.org/<number assigned by issue tracker>
authors: <Author Name>
sponsors: <Sponsor Name>
date: <date when the discussion period starts>
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
---

# Summary

A one-paragraph explanation: motivation and proposed solution.

# Motivation

Describe the problem(s) this GCD attempts to address as clearly as possible
and optionally give an example.  Explain how the status quo is insufficient or
not ideal.

# Detailed Design

Main part.  The sections compares this solution to other options, including
the status quo, and describes the various tradeoffs in this space.  Explain
details, corner cases, provide examples.  Explain it so that someone familiar
can understand.

It is best to exemplify, including with contrived examples. 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 proposed solution.

## Cost of Reverting

This section explains the impact on users and/or community members of the
proposed change, and estimates the effort it would take to revert it.

For code changes, assess the expected impact on existing code or processes on
the following scale:

0. No incompatibility
1. Incompatible only in extremely rare cases (corner cases)
2. Incompatible in rare cases (only visible to advanced users)
3. Unavoidable incompatibility (affecting most)

Describe the migration path and consider how to follow the Deprecation Policy
of the project.

For non-coding activities such as processes of the project, similarly explain
what impact they will have on workflows.

How will your proposed change evolve over time?  What is the cost of changing
or reverting the approach later?

# Drawbacks and Open Issues

At submission time, be upfront about open issues so others in the community
can help.

At the end of the process, this section might be empty.  If not, please be
explicit with the known issues and potential directions to address them.

[-- Attachment #2.5: Type: text/plain, Size: 2639 bytes --]

--

PS: The very first draft had been sent more than one year ago [1,2].
    Then we discussed this topics at Guix Days 2024 [3].  Noé resumed
    [4] on December (more than 40 days ago) and several updates had been
    sent to guix-devel; see v5 [5], v6 [6], v7 [7] etc. v10 [8].  A
    consensus had been reached.

    The discussion is tracked in:

        https://issues.guix.gnu.org/74736


1: Request-For-Comment process: concrete implementation
Simon Tournier <zimon.toutoune@gmail.com>
Tue, 31 Oct 2023 12:14:42 +0100
id:87h6m7yrfh.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-10
https://yhetil.org/guix/87h6m7yrfh.fsf@gmail.com

2: [bug#66844] [PATCH 0/1] Add Request-For-Comment process.
Simon Tournier <zimon.toutoune@gmail.com>
Tue, 31 Oct 2023 12:05:22 +0100
id:cover.1698747252.git.zimon.toutoune@gmail.com
https://issues.guix.gnu.org/66844
https://issues.guix.gnu.org/msgid/cover.1698747252.git.zimon.toutoune@gmail.com
https://yhetil.org/guix/cover.1698747252.git.zimon.toutoune@gmail.com

3: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024/governance.org?id=12a5d469852a008c314c5f30d17ce60f5a954325

4: [bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.
Noé Lopez via Guix-patches via <guix-patches@gnu.org>
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

5: Request-For-Comment process: concrete implementation (v5)
Simon Tournier <zimon.toutoune@gmail.com>
Fri, 03 Jan 2025 19:38:01 +0100
id:87ttafn3p2.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-01
https://yhetil.org/guix/87ttafn3p2.fsf@gmail.com

6: Re: Request-For-Comment process: concrete implementation (v5)
Ludovic Courtès <ludo@gnu.org>
Tue, 07 Jan 2025 11:40:11 +0100
id:87zfk229h0.fsf@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2025-01
https://yhetil.org/guix/87zfk229h0.fsf@gnu.org

7: Guix Common Document process (v7) (was: Request-For-Comment, RFC)
Simon Tournier <zimon.toutoune@gmail.com>
Fri, 10 Jan 2025 01:07:47 +0100
id:87bjwfh6p8.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-01
https://yhetil.org/guix/87bjwfh6p8.fsf@gmail.com

8: Guix Consensus Document process (v10)
Simon Tournier <zimon.toutoune@gmail.com>
Fri, 17 Jan 2025 02:06:23 +0100
id:87bjw6mepc.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2025-01
https://yhetil.org/guix/87bjw6mepc.fsf@gmail.com

[-- Attachment #3: Type: text/plain, Size: 67 bytes --]

-------------------- End of forwarded message --------------------

[bug#74736] [FWD] Guix Consensus Document process – deliberation

[Hilton Chain]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

I support.

> [...]
>        draft                    submitted                   final
> +--------------------+    +---------------------+   +---------------------+
> | Submission Period  |    |  Discussion Period  |   | Deliberation Period |
> |  (up to 7 days)    |-X->|   (30–60 days)      |-->|     (14 days)	      |
> +--------------------+ :  +---------------------+   +---------------------+

Extra tab after "(14 days)" :)

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Hello,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> title: Guix Consensus Document Process
> id: 001
> status: submitted
> discussion: https://issues.guix.gnu.org/74736
> authors: Simon Tournier, Noé Lopez, Ludovic Courtès
> sponsors: pukkamustard, Ricardo Wurmus
> date: 2025-12-08
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
> ---
>
> # Summary
>
> This document describes the _Guix Consensus Document_ (GCD) process of the
> GNU Guix project, later referenced as either Guix or “the project“, for
> brevity.  The GCD 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 the attention of community members on
> important decisions, technical or not, and to give them a chance to weigh
> in.

I support.

\o/

Ludo’.

PS: I guess this can be committed to the new repo now, even in
    ‘submitted’ state, no?  We should add ‘.guix-authorizations’ and a
    keyring branch though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

[bug#74736] Guix Consensus Document process

[Tobias Geerinckx-Rice via Guix-patches via]

I support it.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

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

[Sharlatan Hellseher]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]


I support it.

Member of (starting from the most active) go, python, lisp, science, and
sysadmin teams.

---
Thanks,
Oleg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#74736] Guix Consensus Document process – deliberation

[Liliana Marie Prikler]

Am Mittwoch, dem 22.01.2025 um 20:44 +0100 schrieb Simon Tournier:
> If you are member of a team (etc/teams.scm), you are asked to send by
> email to 74736@debbugs.gnu.org your reply, either:
> 
>  • I support;
I support.


> Someone submitting a patch for any such change may be asked to submit
> an GCD first.
Typo: should be a GCD :)

Cheers

[bug#74736] Guix Consensus Document process – deliberation

[Ekaitz Zarraga]

[-- Attachment #1.1.1: Type: text/plain, Size: 11 bytes --]

I support

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6217 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[jgart via Guix-patches via]

I support

PS

Literally got this when I sent it earlier ;()

Hi!

    This is the MAILER-DAEMON, please DO NOT REPLY to this email.

    An error has occurred while attempting to deliver a message for
    the following list of recipients:

74736@debbugs.gnu.org: 550 This message scored 17.3 spam points.

    Below is a copy of the original message:

Fun times with debbugs
-- 
all the best,
jgart

[bug#74736] Guix Consensus Document process – deliberation

[Tanguy LE CARROUR]

Quoting Simon Tournier (2025-01-22 20:44:08)
> If you are member of a team (etc/teams.scm), you are asked to send by
> email to 74736@debbugs.gnu.org your reply, either:
> 
>  • I support;
>  • I accept;
>  • I disapprove.

I support!

-- 
Tanguy

[bug#74736] Guix Consensus Document process – deliberation

[Janneke Nieuwenhuizen]

Simon Tournier writes:

> Here is the Guix Consensus Document (GCD) process which implements how
> we will collectively make decision on *significant* changes.  Since it
> bootstraps the process, it’s important to have a common understanding of
> it.
>
> If you are member of a team (etc/teams.scm), you are asked to send by
> email to 74736@debbugs.gnu.org your reply, either:
>
>  • I support;
>  • I accept;
>  • I disapprove.

I support!

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#74736] Guix Consensus Document process – deliberation

[Zheng Junjie]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi all,
>
> Here is the Guix Consensus Document (GCD) process which implements how
> we will collectively make decision on *significant* changes.  Since it
> bootstraps the process, it’s important to have a common understanding of
> it.
>
> If you are member of a team (etc/teams.scm), you are asked to send by
> email to 74736@debbugs.gnu.org your reply, either:
>
>  • I support;
>  • I accept;
>  • I disapprove.
>

I support.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#74736] Guix Consensus Document process – deliberation

[Maxim Cournoyer]

Hi,

I support.

-- 
Thanks,
Maxim