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

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

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

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.

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

severity 74736 important

quit

merge 74736 66844

quit

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:

[...]

“… to achieve consensus, lack of a central place to consult contributors

and users, and lack of clear deadlines.”

“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: ”

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…”?

“Detailed Design”

“When To Follow This Process”

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.

Typo: “aforementioned”.

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

I would suggest a separate repo.

s/it might be/it is/

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

mandatory.”

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

below.”

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

stakeholders”.

I would drop that.

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)

…

“The author publicizes their RFC, marking the start of a discussion

period of at least 30 days and at most 60 days.”

“If consensus is reached, the RFC becomes …”

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

Regarding consensus, I would add a link to the “Making Decisions”

section of the manual…

… and drop this.

Maybe we should define the role of “RFC editors” (or “RFC team”?), which

would be the people responsible for doing those changes.

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.

I’m not sure what’s expected in these sections. Maybe “Compatibility

Considerations” would be more appropriate?

I think these two sections in the context of this foundational document

look a bit ridiculous. :-) But maybe that’s okay?

Thanks!

Ludo’.

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

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:

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.

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

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

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?

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

with the template.

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

Hi,

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

Earlier, I wrote:

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

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:

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

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

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

anyone, notably translators, sysadmins, graphics designers, and so on.

¹ Inspired by

https://codeberg.org/mergiraf/mergiraf/src/branch/main/GOVERNANCE.md.

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

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?

There should be a lower limit.

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.

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

Change-Id: Ide88e70dc785ab954ccb42fb043625db12191208

---

rfc/0001-rfc-process.md | 254 ++++++++++++++++++++++++++++++++++++++++

1 file changed, 254 insertions(+)

create mode 100644 rfc/0001-rfc-process.md

Hi Noé,

Thanks for this new version.

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

?

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”):

Thoughts?

Thanks for getting the ball rolling!

Ludo’.

Hi,

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

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

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

Hi Ludo,

I agree (more than less) with all the other comments except this

one. :-)

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

Hi,

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

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.

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

Hi,

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

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

Yes, agreed.

Yes.

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

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

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:

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

Hi Noé,

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

.> and proposed wording:

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?

[...]

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

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

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.

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.

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

back the RFC template.

Agreed.

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

Have a nice day,

Noé

Hi Ludo,

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

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

2:

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

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

OK, got it, we agree on this.

[...]

So are you saying you’d want no quorum at all? (Your revision still

reads “50% committers”.)

OK, will do in the coming days.

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

Thanks,

Ludo’.

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.

Great!

Have a nice day,

Noé

Hi Noé,

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

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

Hi,

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

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.

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

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

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

This is great, thanks! A few comments below:

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

It’s a good place to add:

SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only

Missing a dot at the end of the sentence.

Why the alone dot?

So we are now three authors and no supporters for this RFC? Could we

say that more than one author also works for submitting?

This parenthesis is alone.

Another alone dot ?

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

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

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é

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

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.

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

I filed a support request to create it:

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

Ludo’.

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

Agreed.

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.

Should other dates such as target discussion period end as well as

target deliberation period end also be noted here?

Agreed.

Stating these properties is helpful.

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

I am glad that non-examples were also noted.

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

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.

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.

At that point someone (or some bot) performing cleanup tasks is welcome

to close the issue, if not already closed?

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

Agreed.

Agreed.

^^^^^^^^^^

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

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

I have commented on the issue. If my request to be a supporter is

accepted, I support the above amendment to the target dates.

--

Suhail

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

Repository created!

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

Ludo’.

Hi,

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

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

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.

[...]

[...]

[...]

I suggest: `XY` increments the sequence number.

See above.

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.

I would replace the node ’comments’ by discussion in order to have

something more homogeneous. Nitpicking? ;-)

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.

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

discussion -> deliberation

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

[...]

I would restore the past suggestion to mention the file ’teams.scm’; see

suggestion below (mark **).

---^

) extra

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.

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

clearer.

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.

[...]

[...]

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

[...]

[...]

[...]

Cheers,

simon

Hi,

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

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

I agree this needs a clarification.

Cheers,

simon

Hi,

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

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

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

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

I agree.

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 agree. I remember your suggestion at the last Guix Days. And I lost

it among other stuff during the year 2024… Arf!

Thank you.

Ah what a pity to not see you in Brussels!

Cheers,

simon

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

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

documents.)

Ludo’.

Hello pukkamustard,

Thanks for insightful comments!

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

A mistake of mine in v6; we should reintroduce a mention of

‘etc/teams.scm’ or a reference to the manual.

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

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

We could state that anything that comes before or after the Deliberation

Period is ignored, to avoid the ambiguity.

Agreed (that was an omission).

Oops, agreed.

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.

Heheh.

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

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

Ludo’.

Hello,

(Stripping comments/suggestions I agree with.)

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

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.

You mean that this (soliciting opinions) is something

supporters/sponsors should do, right? I agree.

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

OK.

Agreed.

I’ll send v7 tomorrow.

Thank you!

Ludo’.

Hi Ludo,

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

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,

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

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

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

--

Hi Ludo,

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

Heh me too. Although the dot provides a bit more information via the

name of the nodes. Bah I don’t know.

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

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:

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

Ludovic Courtès writes:

Hello,

[..]

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?

So, in effect a "noise" filter / focus mechanism for the most important

changes. That seems like a very good idea to me!

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.

[..]

^

"long" typo?

Greetings,

Janneke

--

Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org

Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com

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

Hi Simon,

Can you explain the reasoning for that name? I don’t think I understand

what it means.

Thanks,

Noé

Hi,

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

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?

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?

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

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?

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

Hi Janneke,

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

[...]

[...]

Yes! :-)

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

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.

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

Hi Noé,

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

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

Simon Tournier writes:

Hi Simon,

[..]

[..]

Great!

Yes, I tend to agree. Especially improving the chance to get involved

is a very good thing.

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.

Noted. Sorry for being sloppy with the terms :)

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

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

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

Thanks,

Noé

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:

And v8:

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

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

On 2025-01-10, Simon Tournier wrote:

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

It does seem clearer, but the match between "I disapprove" and

disapproves is probably sufficient to address my concern.

That is my understanding...

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.

Sounds good to me, sure!

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.

At least the major points of disapproval should be summarized succinctly

somewhere. I am not terribly particular about where. :)

Yeah, something along those lines.

live well,

vagrant

Hi Hartmut,

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

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:

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.

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

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.

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

I proposed “Voting Period” but we eventually considered that

“Deliberation Period” would better represent what this is.

You propose what? :-)

Thanks,

Ludo’.

Hello all,

thank you for moving this forward! May I suggest to keep guix-devel

posted when sending comments to the bug?

I like Arun's suggestion of having a separate mailing list for

discussing these important changes (GCD? Greatest common divisors!)

in the future instead of guix-devel.

Janneke, I think another motivation for such a process is to make sure

that some decision is actually reached in the end, instead of letting

discussions taper out. I feel that this tends to happen in Guix and Guix

Foundation.

Concerning consensus, I am mildly worried about deadlocks (including

when trying to modify this RFC/GCD). What happens if some person insists

on disapproving? (I am reminded of the European Union where one member

state can effectively hold the others hostage over certain issues.)

The RFC/GCD says: "A team member sending this reply should have made

constructive comments during the discussion period." What if they have

not? How about adding a quorum of "disapprove" votes to have effect?

(Actually in Europe *two* member states are needed for a veto in the

Council.)

Notice also that the suggestion bootstraps the team members into a

decision taking body - so far we have added people more or less randomly

to teams. For instance, team members need not have commit rights and

thus be vetted by three fellow committers. So should we replace "team

members" by "committers"? Or keep the proposal as is and immediately

work on a new GCD to somehow safeguard the addition of people to a team?

Andreas

Hello Andreas,

On 2025-01-15 15:34, Andreas Enge wrote:

I wonder whether the 'political ability' of somebody being able to use

deadlock leavers

should be limited to those who are active/recent members.

Does it seem sensible to have this in place already?