guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#61894: [PATCH RFC] Team approval for patches


From: Simon Tournier
Subject: Re: bug#61894: [PATCH RFC] Team approval for patches
Date: Thu, 09 Mar 2023 10:46:08 +0100

Hi Maxim,

On Wed, 08 Mar 2023 at 12:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> On a side note, it would also introduce some kind of hierarchy in the
> group, which I dislike.  One of the things that make Guix special is
> that it's pretty flat -- everybody can participate at the same level, at
> least between committers).  I'd rather we don't try to emulate Debian on
> that point.

Hierarchy already exists, as in any social group, as in any group of
people collaborating.  The hierarchy is currently informal.

And it is not really “pretty flat” because some individuals from that
group have more (informal) power than other.  That’s not necessary a bad
thing. :-) For instance, the access to the build farms is restricted,
the ability to restart Cuirass job is restricted, commit access is
restricted, money spending is restricted, etc.

What I see as a bad thing is the informal part.

Far from me the willing of being confrontational, I just would like to
point that you are somehow on the top of the “hierarchy” so you see it
as “pretty flat”, when it is not.  And if you want to experiment, try to
spend one month using only guix-devel and guix-patches for collaborating
and you will see. :-)

That’s said, Guix is awesome!  I came because technical features and I
am still here because the community is welcoming, friendly, helping and
I really enjoy the way we are collaborating altogether.

I totally agree that everyone can participate and we, as a group, are
trying hard to be welcoming and friendly, so that everybody can
participate and/or acquire more knowledge and/or skill, and from my
point of view, we try hard to take into account all the voices.  By
daily interactions, we are doing our best in this area – even often
rehashing how we can improve.  And for what it is worth, I will do all
my best so that this will not change. :-)

Now, we, as a community of volunteers, have one problem, well, two
related problems:

  (1) not enough people are reviewing
  (2) there is no “duty” or “accountability”

These is becoming more apparent because Guix is growing and that’s a
good thing.  And we have to adapt our practices for a better scaling, IMHO.

This “teams” is somehow a proposal as an attempt to address (1) and (2).

Please, do not take me wrong with the quoted duty and accountability.

Motivation by volunteers is non-fungible, for sure.  That’s does not
mean that a subgroup cannot commit for some tasks.  That’s already the
case, guix-maintainers is committed to “duties” as explained by [1].
For instance, it reads « the other responsibilities can be delegated:

    - Making releases.

    - Dealing with development and its everyday issues as well as …

    - Participating in [internship progam]

    - Organizing [events]

    - Taking care of Guix money …

    - Keeping the build farm infrastructure up

    - Keeping the web site up-to-date.

    - Looking after people
»

Therefore, could you please point me who or how these responsibilities
are delegated?  From my point of view, “teams” is an attempt to
accomplish that delegation.

Me too, I am not convinced that the heavy “bureaucracy“ of Debian is
something that I would like with Guix.  However, there is gap between
the addition of more explicit structure in Guix as “teams” is a proposal
and keep the current informal structure.

Cheers,
simon

1: https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]