GNU bug report logs - #61894
[PATCH RFC] Team approval for patches

Previous Next

Full log

Message #35 received at 61894 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 61894 <at> debbugs.gnu.org,
 guix-maintainers <at> gnu.org
Subject: Re: [bug#61894] [PATCH RFC] Team approval for patches
Date: Mon, 06 Mar 2023 22:42:29 +0100

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> It sounds reasonable and a good change "on paper", but in practice I
> think it may be too soon to formalize teams that way.  Teams are a
> nascent concept which hasn't reached a point we can rely on it, in my
> opinion.  We are still ironing out kinks in the tools [0] :-).  I'd
> prefer we stay as nimble/agile as we can and maximize the potential of
> our large committers pool for now, at the expense of sometimes having to
> retroactively discussing/fixing up or reverting some change that wasn't
> up to par, that could have possibly been caught by a more focused team.

I think formalizing collaboration would be the way to “maximize the
potential of our large committer pool”: by having clear rules, we make
it easier to work together, not harder.

Retroactively fixing, reverting, or discussing often causes unnecessary
friction and puts pressure on the collective.  Discussion should always
happen before the fact.

We’ve reached the point where the code base is large and the experiences
of individual contributors vary.  To cope with that, I think we need to
communicate and coordinate more to have a shared understanding of the
code, of our goals, of our needs and expectations.  We can no longer
rely on implicitness and the idea that silence is consent.

This proposal is one possible step in that direction, but I’m open to
other approaches.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.