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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

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

> Hello Guix!
>
> The project has been steadily gaining new contributors, which is great,
> and I think we need to adjust our processes accordingly.
>
> Currently teams are described mostly as pools of people who can mentor
> contributors in a particular area and who can review patches in that
> area.  My proposal is to give teams formal approval power over changes
> to code in their area.
>
> This is sorta happening already, but informally: if a non-committer
> sends a patch, someone from the team eventually “approves” it by pushing
> it.  Within a team, the situation is different: people usually discuss
> changes, and the submitter (also committer) eventually pushes them;
> sometimes, the submitter pushes changes without getting approval (or
> feedback) from others on the team.
>
> With the proposed policy, members of a team would also have to review
> and approve each other’s work.  Formal approval means getting an
> explicit “LGTM” (or similar) from at least one other team member.
>
> This is similar to the review thresholds found on GitLab & co., where
> project admins can specify a minimum number of approvals required before
> a change is marked as ready.  I think it avoids the unavoidable
> misunderstandings that can arise in a growing group and help pacify
> day-to-day collaboration.
>
> Below is a suggested change.
>
> What do people think?
>
> Ludo’.

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.

[0] https://issues.guix.gnu.org/58813

-- 
Thanks,
Maxim