[Top][All Lists]

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

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

From: Ludovic Courtès
Subject: Re: [bug#61894] [PATCH RFC] Team approval for patches
Date: Mon, 06 Mar 2023 22:42:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)


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


reply via email to

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