Request-For-Comment process: concrete implementation

Request-For-Comment process: concrete implementation

[Simon Tournier]

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

Hi,

This is a proposal for implementing Request-For-Comment process.
Comment are welcome in #66844 [1]:

    1: https://issues.guix.gnu.org/issue/66844


The proposal is highly inspired by Rust RFC:

    https://github.com/rust-lang/rfcs

and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
on my understanding of Guix community interactions, I write down this
text; below the text for easing the reading.

Cheers,
simon

1: https://github.com/ghc-proposals/ghc-proposals
2: https://github.com/NixOS/rfcs

--

RFC process
===========


[-- Attachment #2: rfc.txt --]
[-- Type: text/plain, Size: 7678 bytes --]

# -*- mode:org -*-
#+TITLE: Request-For-Comment process
#+DATE: 2023-10-31

+ Issue: 66844
+ Status: pending
+ Supporter: Simon Tournier
+ Co-supporters:

* Summary

The "RFC" (request for comments) process is intended to provide a consistent
and controlled path for new features to enter the Guix project, so that all
stakeholders can be confident about the direction it is evolving in.

* Motivation

The freewheeling way that we add new features to Guix has been good for early
development, but for Guix to become a broadly used system we need to develop
some more self-discipline when it comes to changing our beloved system.  This
is a proposal for a more principled RFC process to make it a more integral
part of the overall development process, and one that is followed consistently
to introduce substancial features.

There are a number of changes that are significant enough that they could
benefit from wider community consensus before being introduced.  Either
because they introduce new concepts, big changes or are controversial enough
that not everybody will agree on the direction to take.

Therefore, the purpose of this RFC is to introduce a process that allows to
bring the discussion upfront and strengthen decisions.  This RFC is used to
bootstrap the process and further RFCs can be used to refine the process.

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

 + change of inputs style
   (Removing input labels from package definitions, #49169)
 + introduction of =guix shell= and deprecation of =guix environment=
   (Add 'guix shell' to subsume 'guix environment', #50960)
 + introduction of authentication mechanism (Trustable "guix pull", #22883)
 + massive Python 2 removal
   (Merging the purge-python2-packages branch, mailing list guix-devel)
 + collaboration via team and branch-features
   (several places mailing list guix-devel)

* Detail design

** When you need to follow this process

This process is followed when one intends to make "substantial" changes to the
Guix project.  What constitutes a "substantial" change is evolving based on
community norms, but may include the following.

  + Any change that modifies Guix API
  + Big restructuring of packages
  + Introduction or removal of subcommands

Certain changes do not require an RFC:

  - Adding, updating packages, removing outdated packages
  - Fixing security updates and bugs that don't break interfaces

A patch submission to Debbugs that contains any of the afore-mentioned
substantial changes may be asked to first submit a RFC.

** How the process works

  1. Clone https://git.savannah.gnu.org/git/guix.git
  2. Copy rfc/0000-template.org to rfc/00XY-good-name.org where good-name is
     descriptive but not too long and XY increments
  3. Fill RFC
  4. Submit to guix-patches@gnu.org

Make sure the proposal is as well-written as you would expect the final
version of it to be.  It does not mean that all the subtilities must be
considered at this point since that is the aim of review discussion.  It means
that the RFC process is not a prospective brainstorming and the proposal
formalize an idea for making it happen.

The submission of a proposal does not require an implementation.  However, to
improve the chance of a successful RFC, it might be recommended to have an
idea for implementing it.  If an implementation is attached to the detailed
design, it might help the discussion.

At this point, at least one other person must volunteer to be "co-supporter".
The aim is to improve the chances that the RFC is both desired and likely to
be implemented.

Once supporter and co-supporter(s) are committed in the RFC process, the
review discussion starts.  Advertisement of the RFC on the mailing-lists
guix-devel is mandatory and IRC is recommended.

After a number of rounds of review, the discussion should settle and a general
consensus should emerge.  If the RFC is successful then authors may contribute
to the implementation.  This bit is left intentionally vague and should be
refined in the future.

A successful RFC is not a rubber stamp, and in particular still does not mean
the feature will ultimately be merged; it does mean that in principle all the
major stakeholders have agreed to the feature and are amenable to merging it.

An unsuccessful RFC is *not* a judgment on the value of the work, so a refusal
should rather be interpreted as “let’s discuss again with a different angle”.
The last state of an unsuccessful RFC is archived under the directory
rfcs/unsuccessful/.

** Co-supporter

A co-supporter is a contributor sufficiently familiar with the project’s
practices, hence it is recommended, but not mandatory, to be a contributor
with commit access.  The co-supporter helps the supporter, they are both
charged with keeping the proposal moving through the process.  The
co-supporter role is to help the proposal supporter by being the timekeeper
and helps in pushing forward until process completion.

The co-supporter doesn't necessarily have to agree with all the points of the
RFC but should generally be satisfied that the proposed additions are a good
thing for the community.

** Comment period

It is up to the supporter and co-supporter to ensure that sufficient
discussion is solicited.  Let two weeks for people to comment is a good
average.  Make sure that all have the time for expressing their comments.  The
proposal is about significant changes, thus more time is better than less.

** Decision making: consensus

It is expected from all contributors, and even more so from committers, to
help build consensus and make decisions based on consensus.  By using
consensus, we are committed to finding solutions that everyone can live with.

It implies that no decision is made against significant concerns and these
concerns are actively resolved with proposals that work for everyone.  A
contributor, without or with commit access, wishing to block a proposal bears
a special responsibility for finding alternatives, proposing ideas/code or
explaining the rationale for the status quo.

To learn what consensus decision making means and understand its finer
details, you are encouraged to read
<https://www.seedsforchange.org.uk/consensus>.

** Merging the outcome

Whoever merges the successful RFC should do the following:

 1. Fill in the remaining metadata in the RFC header, including links for the
    original Debbugs submission.
 2. Commit everything.

** Template of RFC

The structure of the RFC is captured by the template; see the file
rfc/0000-template.txt.  It is recommended to write using markup language as,
for example, Org-mode or Markdown or reStructuredText.

** Backward Compatibility

None.

** Drawbacks

There is a risk that the additional process will hinder contribution more than
it would help.  We should stay alert that the process is only a way to help
contribution, not an end in itself.

Of course, group decision-making processes are difficult to manage.

The ease of commenting may bring a slightly diminished signal-to-noise ratio
in collected feedback, particularly on easily bike-shedded topics.

** Open questions

There are still questions regarding the desired scope of the process.  While
we want to ensure that changes which affect the users are well-considered, we
certainly don't want the process to become unduly burdensome.  This is a
careful balance which will require care to maintain moving forward.

* Unresolved questions

Re: Request-For-Comment process: concrete implementation

[Ludovic Courtès]

Hello,

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

> This is a proposal for implementing Request-For-Comment process.
> Comment are welcome in #66844 [1]:
>
>     1: https://issues.guix.gnu.org/issue/66844

Thanks for starting the discussion!  I think that getting such a process
in place is key to sustain friction-less development of Guix, giving
everyone a chance to have their voice heard.

Ludo’.

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Ludo,

Thanks for giving a look.

On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès <ludo@gnu.org> wrote:

> Thanks for starting the discussion!  I think that getting such a process
> in place is key to sustain friction-less development of Guix, giving
> everyone a chance to have their voice heard.

Do you have comments on the current proposal?  About points where you
think they could be improved?  As wording?  Or process?  Or else?

Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Ludovic Courtès]

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

> On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Thanks for starting the discussion!  I think that getting such a process
>> in place is key to sustain friction-less development of Guix, giving
>> everyone a chance to have their voice heard.
>
> Do you have comments on the current proposal?  About points where you
> think they could be improved?  As wording?  Or process?  Or else?

I haven’t taken the time to look at it yet but plan to do so.

Thanks,
Ludo’.

Re: Request-For-Comment process: concrete implementation

[Efraim Flashner]

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

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

I think this is a great idea and that we should implement it. Looking
through it I didn't see anything that jumped out to me as something that
needed to be changed.

Currently we have largish changes split between guix-patches and
guix-devel, with no real clear way to draw people's attention to them.
Currently I'm aware of re-arranging the go packages, splitting some of
the system services into their own modules, I'd like to add a field to
(guix platform), it'd be good to formalize some of these processes to
make it clearer about what's expected and what's going on.

Actually, in terms of suggestions, I'd add the rfc/ folder in
etc/teams.scm to set guix-devel as one of the team members.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Efraim,

Thnaks for your comments.

On Thu, 23 Nov 2023 at 09:04, Efraim Flashner <efraim@flashner.co.il> wrote:

> Actually, in terms of suggestions, I'd add the rfc/ folder in
> etc/teams.scm to set guix-devel as one of the team members.

Good idea!

Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi,

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

WDYT about the proposal?

On Tue, 31 Oct 2023 at 12:14, Simon Tournier <zimon.toutoune@gmail.com> wrote:
> Hi,
>
> This is a proposal for implementing Request-For-Comment process.
> Comment are welcome in #66844 [1]:
>
>     1: https://issues.guix.gnu.org/issue/66844
>
>
> The proposal is highly inspired by Rust RFC:
>
>     https://github.com/rust-lang/rfcs
>
> and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
> on my understanding of Guix community interactions, I write down this
> text; below the text for easing the reading.
>
> Cheers,
> simon
>
> 1: https://github.com/ghc-proposals/ghc-proposals
> 2: https://github.com/NixOS/rfcs
>
> --
>
> RFC process
> ===========
>
> # -*- mode:org -*-
> #+TITLE: Request-For-Comment process
> #+DATE: 2023-10-31
>
> + Issue: 66844
> + Status: pending
> + Supporter: Simon Tournier
> + Co-supporters:
>
> * Summary
>
> The "RFC" (request for comments) process is intended to provide a consistent
> and controlled path for new features to enter the Guix project, so that all
> stakeholders can be confident about the direction it is evolving in.
>
> * Motivation
>
> The freewheeling way that we add new features to Guix has been good for early
> development, but for Guix to become a broadly used system we need to develop
> some more self-discipline when it comes to changing our beloved system.  This
> is a proposal for a more principled RFC process to make it a more integral
> part of the overall development process, and one that is followed consistently
> to introduce substancial features.
>
> There are a number of changes that are significant enough that they could
> benefit from wider community consensus before being introduced.  Either
> because they introduce new concepts, big changes or are controversial enough
> that not everybody will agree on the direction to take.
>
> Therefore, the purpose of this RFC is to introduce a process that allows to
> bring the discussion upfront and strengthen decisions.  This RFC is used to
> bootstrap the process and further RFCs can be used to refine the process.
>
> Note that this process does not cover most of the changes.  It covers
> significant changes, for some examples:
>
>  + change of inputs style
>    (Removing input labels from package definitions, #49169)
>  + introduction of =guix shell= and deprecation of =guix environment=
>    (Add 'guix shell' to subsume 'guix environment', #50960)
>  + introduction of authentication mechanism (Trustable "guix pull", #22883)
>  + massive Python 2 removal
>    (Merging the purge-python2-packages branch, mailing list guix-devel)
>  + collaboration via team and branch-features
>    (several places mailing list guix-devel)
>
> * Detail design
>
> ** When you need to follow this process
>
> This process is followed when one intends to make "substantial" changes to the
> Guix project.  What constitutes a "substantial" change is evolving based on
> community norms, but may include the following.
>
>   + Any change that modifies Guix API
>   + Big restructuring of packages
>   + Introduction or removal of subcommands
>
> Certain changes do not require an RFC:
>
>   - Adding, updating packages, removing outdated packages
>   - Fixing security updates and bugs that don't break interfaces
>
> A patch submission to Debbugs that contains any of the afore-mentioned
> substantial changes may be asked to first submit a RFC.
>
> ** How the process works
>
>   1. Clone https://git.savannah.gnu.org/git/guix.git
>   2. Copy rfc/0000-template.org to rfc/00XY-good-name.org where good-name is
>      descriptive but not too long and XY increments
>   3. Fill RFC
>   4. Submit to guix-patches@gnu.org
>
> Make sure the proposal is as well-written as you would expect the final
> version of it to be.  It does not mean that all the subtilities must be
> considered at this point since that is the aim of review discussion.  It means
> that the RFC process is not a prospective brainstorming and the proposal
> formalize an idea for making it happen.
>
> The submission of a proposal does not require an implementation.  However, to
> improve the chance of a successful RFC, it might be recommended to have an
> idea for implementing it.  If an implementation is attached to the detailed
> design, it might help the discussion.
>
> At this point, at least one other person must volunteer to be "co-supporter".
> The aim is to improve the chances that the RFC is both desired and likely to
> be implemented.
>
> Once supporter and co-supporter(s) are committed in the RFC process, the
> review discussion starts.  Advertisement of the RFC on the mailing-lists
> guix-devel is mandatory and IRC is recommended.
>
> After a number of rounds of review, the discussion should settle and a general
> consensus should emerge.  If the RFC is successful then authors may contribute
> to the implementation.  This bit is left intentionally vague and should be
> refined in the future.
>
> A successful RFC is not a rubber stamp, and in particular still does not mean
> the feature will ultimately be merged; it does mean that in principle all the
> major stakeholders have agreed to the feature and are amenable to merging it.
>
> An unsuccessful RFC is *not* a judgment on the value of the work, so a refusal
> should rather be interpreted as “let’s discuss again with a different angle”.
> The last state of an unsuccessful RFC is archived under the directory
> rfcs/unsuccessful/.
>
> ** Co-supporter
>
> A co-supporter is a contributor sufficiently familiar with the project’s
> practices, hence it is recommended, but not mandatory, to be a contributor
> with commit access.  The co-supporter helps the supporter, they are both
> charged with keeping the proposal moving through the process.  The
> co-supporter role is to help the proposal supporter by being the timekeeper
> and helps in pushing forward until process completion.
>
> The co-supporter doesn't necessarily have to agree with all the points of the
> RFC but should generally be satisfied that the proposed additions are a good
> thing for the community.
>
> ** Comment period
>
> It is up to the supporter and co-supporter to ensure that sufficient
> discussion is solicited.  Let two weeks for people to comment is a good
> average.  Make sure that all have the time for expressing their comments.  The
> proposal is about significant changes, thus more time is better than less.
>
> ** Decision making: consensus
>
> It is expected from all contributors, and even more so from committers, to
> help build consensus and make decisions based on consensus.  By using
> consensus, we are committed to finding solutions that everyone can live with.
>
> It implies that no decision is made against significant concerns and these
> concerns are actively resolved with proposals that work for everyone.  A
> contributor, without or with commit access, wishing to block a proposal bears
> a special responsibility for finding alternatives, proposing ideas/code or
> explaining the rationale for the status quo.
>
> To learn what consensus decision making means and understand its finer
> details, you are encouraged to read
> <https://www.seedsforchange.org.uk/consensus>.
>
> ** Merging the outcome
>
> Whoever merges the successful RFC should do the following:
>
>  1. Fill in the remaining metadata in the RFC header, including links for the
>     original Debbugs submission.
>  2. Commit everything.
>
> ** Template of RFC
>
> The structure of the RFC is captured by the template; see the file
> rfc/0000-template.txt.  It is recommended to write using markup language as,
> for example, Org-mode or Markdown or reStructuredText.
>
> ** Backward Compatibility
>
> None.
>
> ** Drawbacks
>
> There is a risk that the additional process will hinder contribution more than
> it would help.  We should stay alert that the process is only a way to help
> contribution, not an end in itself.
>
> Of course, group decision-making processes are difficult to manage.
>
> The ease of commenting may bring a slightly diminished signal-to-noise ratio
> in collected feedback, particularly on easily bike-shedded topics.
>
> ** Open questions
>
> There are still questions regarding the desired scope of the process.  While
> we want to ensure that changes which affect the users are well-considered, we
> certainly don't want the process to become unduly burdensome.  This is a
> careful balance which will require care to maintain moving forward.
>
> * Unresolved questions

Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Ricardo Wurmus]

Hi Simon,

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

I just got back from travels and finally caught up with important email.
I read the proposal and it looks good to me.  Thank you for working on
this!

This would be the first project I contribute to that has an RFC process,
so I don’t know what to look out for.  My concerns may thus be
completely out of touch with reality, so beware as you read on.

It seems to me that the exact process is a little vague, especially with
regard to how long the comment period should be, and what expectations
there are during this period.  There is a chance that the open comment
period will lead to derailing discussions of tangents that make it hard
for the submitter to answer to real issues (because it would become
increasingly difficult to read all messages).

I’m thinking of some of the big discussions on the devel list in the
past that became too big to follow, and resulted in “consensus by
attrition”.  Do you know how other projects avoid needlessly dragging on
discussions about RFCs?

Will *any* disagreement have to be addressed, or will there be an
implicit weighing of opinions?  As the project grows bigger there can be
a problem of having inexperienced contributors (or those with
qualifications that are irrelevant to the proposal) block the RFC
without malicious intent by essentially requiring to be tutored on areas
outside of their expertise.

I wouldn’t trust myself to write an RFC without having played with an
implementation first.  I have doubts whether RFCs that are written
without a proof of concept could reasonably be evaluated.  Often details
and subtle problems are discovered only when playing with a patch, and
this may happen only after an RFC has been accepted.  Can we take back
approval in this RFC process?

And lastly a typo:

* “subtilities” should probably be “subtleties”.

-- 
Ricardo

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Ricardo,

On mer., 20 déc. 2023 at 12:49, Ricardo Wurmus <rekado@elephly.net> wrote:

> I just got back from travels and finally caught up with important email.
> I read the proposal and it looks good to me.  Thank you for working on
> this!
>
> This would be the first project I contribute to that has an RFC process,
> so I don’t know what to look out for.  My concerns may thus be
> completely out of touch with reality, so beware as you read on.

Thank you for the feedback.  Much appreciated! :-)

I will address your question in another broad message.

Cheers,
simon

[post Guix Days] Guix Common Document (was: Request-For-Comment process)

[Simon Tournier]

Hi all,

I hope that the discussion we had yesterday (Friday 2nd) in Guix Days
has clarified the idea behind this proposal.

I am waiting Ludo’s notes in order to refine this proposal, integrate
many comments and/or ideas, and polish.

Thanks all participants.


The aim of the proposal is to have a process to document our processes
with the least bureaucracy as possible.  Well, Debian project is often
cited as an example (social contract, voting system, etc.).  Indeed,
however there is more bureaucracy in Debian than in French State. ;-)

Instead, let just formalize what we are already doing.

Currently, we are just adding more and more sections to the manual and
for other parts the structure for making decisions is not clear.  For
sure, it works… until now but I think it does not scale and we are
touching the limits about what can be done with this informal structure.

Let me clarify my attempt behind this “RFC proposal”.  First,
pukkamustard proposed the name “Guix Common Document” echoing “greatest
common divisor“ (gcd): the greatest common divisor of two or more
integers is the largest positive integer that divides each of the
integers – other said, that’s the larger integer in common with all.

I like it because it captures well the idea; although such different
name could be confusing from the outside.   Anyway.  That’s an
implementation detail. ;-)

Second, from my point of view, the core components of the proposal are:

 + consensus;
 + co-supporter.

Consensus, because it is how we already collaborate.  Somehow, it
changes almost nothing for our daily operations but having an explicit
formalization will help outsiders.  The definition of “consensus” is
twofold:

 1. can live with;
 2. concerns are actively resolved.

Other said, the definition wording of “consensus” specifies how to avoid
being blocked by disagreements: when one wish to block a proposal then
one bears a special responsibility for finding alternatives, proposing
ideas/code or explaining the rationale for the status quo.

And to make it clear, the first idea for making decision is “voting” but
then we need to define “who” votes.  Well, this appears to me a
counter-measure against something that would be rare and this solution
does not trust in the values of our community (being welcoming,
inclusive, taking care of each other, etc. well as least, trying as much
as possible :-)).

For me, the counter-measure against an hostile takeover is somehow
captured the point #2 above.


Co-supporter, because similarly as the manual section « (guix) Reviewing
the Work of Others » [1], the aim is to cross the final line, make
progress by incremental focused improvements.  Therefore, a proposal
needs the help of someone committed to the project (long-standing
contributor, committer, etc.).

I agree that “contributor sufficiently familiar” is maybe too vague and
needs more specific examples as “contributor sufficiently familiar
(committers or people with X commits)”.  Well, that’s part refining the
proposal. :-)


Last, I think that the time-frame for discussing needs to be bounded.
Somehow this bound will help in the incremental improvement and will
avoid the trap of the perfect-as-the-first-try.


Well, let recover from these awesome Guix Days and from FOSDEM and then
resume this proposal.

Cheers,
simon

1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others

Re: [post Guix Days] Guix Common Document (was: Request-For-Comment process)

[Efraim Flashner]

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

On Sat, Feb 03, 2024 at 11:34:13AM +0100, Simon Tournier wrote:
> Hi all,
> 
> I hope that the discussion we had yesterday (Friday 2nd) in Guix Days
> has clarified the idea behind this proposal.
> 
> I am waiting Ludo’s notes in order to refine this proposal, integrate
> many comments and/or ideas, and polish.
> 
> Thanks all participants.
> 
> 
> The aim of the proposal is to have a process to document our processes
> with the least bureaucracy as possible.  Well, Debian project is often
> cited as an example (social contract, voting system, etc.).  Indeed,
> however there is more bureaucracy in Debian than in French State. ;-)
> 
> Instead, let just formalize what we are already doing.
> 
> Currently, we are just adding more and more sections to the manual and
> for other parts the structure for making decisions is not clear.  For
> sure, it works… until now but I think it does not scale and we are
> touching the limits about what can be done with this informal structure.
> 
> Let me clarify my attempt behind this “RFC proposal”.  First,
> pukkamustard proposed the name “Guix Common Document” echoing “greatest
> common divisor“ (gcd): the greatest common divisor of two or more
> integers is the largest positive integer that divides each of the
> integers – other said, that’s the larger integer in common with all.
> 
> I like it because it captures well the idea; although such different
> name could be confusing from the outside.   Anyway.  That’s an
> implementation detail. ;-)
> 
> Second, from my point of view, the core components of the proposal are:
> 
>  + consensus;
>  + co-supporter.
> 
> Consensus, because it is how we already collaborate.  Somehow, it
> changes almost nothing for our daily operations but having an explicit
> formalization will help outsiders.  The definition of “consensus” is
> twofold:
> 
>  1. can live with;
>  2. concerns are actively resolved.
> 
> Other said, the definition wording of “consensus” specifies how to avoid
> being blocked by disagreements: when one wish to block a proposal then
> one bears a special responsibility for finding alternatives, proposing
> ideas/code or explaining the rationale for the status quo.
> 
> And to make it clear, the first idea for making decision is “voting” but
> then we need to define “who” votes.  Well, this appears to me a
> counter-measure against something that would be rare and this solution
> does not trust in the values of our community (being welcoming,
> inclusive, taking care of each other, etc. well as least, trying as much
> as possible :-)).
> 
> For me, the counter-measure against an hostile takeover is somehow
> captured the point #2 above.
> 
> 
> Co-supporter, because similarly as the manual section « (guix) Reviewing
> the Work of Others » [1], the aim is to cross the final line, make
> progress by incremental focused improvements.  Therefore, a proposal
> needs the help of someone committed to the project (long-standing
> contributor, committer, etc.).
> 
> I agree that “contributor sufficiently familiar” is maybe too vague and
> needs more specific examples as “contributor sufficiently familiar
> (committers or people with X commits)”.  Well, that’s part refining the
> proposal. :-)

For this part I think that for 'contributor sufficiently familiar' can
be interpreted as someone sufficiently familiar with Guix, the coding
standards, etc., and it could also be interpreted as someone
sufficiently familiar with the subject matter being proposed. For
example, I don't know about AVR chips or programming them or knowing
what to do with them, but I can review the code submitted to make sure
it doesn't break other functionality already included in Guix and rely
on others telling me that they've tested out the code and it works with
their chips.

> Last, I think that the time-frame for discussing needs to be bounded.
> Somehow this bound will help in the incremental improvement and will
> avoid the trap of the perfect-as-the-first-try.
> 
> 
> Well, let recover from these awesome Guix Days and from FOSDEM and then
> resume this proposal.
> 
> Cheers,
> simon
> 
> 1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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