[PATCH RFC] Team approval for patches

Open

Details

12 participants

Andreas Enge
Björn Höfling
bokr
Efraim Flashner
Felix Lechner
宋文武
Leo Famulari
Ludovic Courtès
Christopher Baines
Maxim Cournoyer
Vagrant Cascadian
Simon Tournier

Owner: unassigned

Submitted by: Ludovic Courtès

Severity: normal

Ludovic Courtès wrote on 1 Mar 17:13 +0100

Recipients:(address . guix-patches@gnu.org)

Message-ID:878rgga1qv.fsf@inria.fr

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’.

Toggle diff (40 lines)diff --git a/doc/contributing.texi b/doc/contributing.texi
index c436bc4a31..d8ca6802c4 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1486,7 +1486,7 @@ reply to incoming bugs and patches, which contains the bug number.
 @anchor{Notifying Teams}
 @cindex teams
 The @file{etc/teams.scm} script may be used to notify all those who
-may be interested in your patch of its existence (@pxref{Teams}).
+may be interested in your patch and may approve it (@pxref{Teams}).
 Use @command{etc/teams.scm list-teams} to display all the teams,
 decide which team(s) your patch relates to, and use
 @command{etc/teams.scm cc} to output various @command{git send-email}
@@ -1557,6 +1557,9 @@ these changes are necessary.
 @subsection Teams
 @cindex teams
 
+The project is structured as @dfn{teams}, which play two related roles:
+mentoring people who contribute code in their area of expertise, and
+reviewing and approving changes to that code.
 There are several teams mentoring different parts of the Guix source
 code.  To list all those teams, you can run from a Guix checkout:
 
@@ -1840,8 +1843,14 @@ Patches}).  It also allows patches to be picked up and tested by the
 quality assurance tooling; the result of that testing eventually shows
 up on the dashboard at
 @indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where
-@var{ISSUE_NUMBER} is the number assigned by the issue tracker.  Leave
-time for a review, without committing anything (@pxref{Submitting
+@var{ISSUE_NUMBER} is the number assigned by the issue tracker.
+
+When your patch falls under the area of expertise of a team
+(@pxref{Teams}), you need the explicit approval of at least one team
+member before committing (another team member if you are on the team).
+
+In other cases,
+leave time for a review, without committing anything (@pxref{Submitting
 Patches}).  If you didn’t receive any reply after one week (two weeks
 for more significant changes), and if you're confident, it's OK to
 commit.

Christopher Baines wrote on 1 Mar 18:15 +0100

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:871qm8wf8e.fsf@cbaines.net

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

Toggle quote (22 lines)> 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.

I guess I'm still a team sceptic, I think the idea is interesting and I

have added myself as a member of some teams. But the main impact on me

so far is that I've just been getting some unwanted personal email,

messages that previously wouldn't have landed in my inbox have been

doing so.

Regarding this change specifically though, I'm unclear how it would

impact the things I push for others. I pushed some patches today, would

this mean that I'd have to look at what team/teams are involved

(according to /etc/teams.scm.in) for each commit/series, and then either

continue if I'm a member of that team, or skip it if I'm not?

If I'm going to not be pushing stuff I would have previously pushed

because I'm not in the relevant teams, maybe I should just add myself to

every team? I guess this is not a serious question, but I'm more making

the point that if teams become a formal part of patch review, then some

formalities over membership of a team is probably a prerequsite.

As a point of clarification, if a patch or series touches files that

fall within the scope of several teams, am I correct in saying that this

change would require approval from all teams?

Thanks,

Chris

Björn Höfling wrote on 1 Mar 18:59 +0100

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)

Message-ID:20230301185919.56734797@tangletp

On Wed, 01 Mar 2023 17:15:26 +0000

Christopher Baines <mail@cbaines.net> wrote:

Toggle quote (12 lines)> I guess I'm still a team sceptic, I think the idea is interesting and
> I have added myself as a member of some teams. But the main impact on
> me so far is that I've just been getting some unwanted personal email,
> messages that previously wouldn't have landed in my inbox have been
> doing so.
> 
> Regarding this change specifically though, I'm unclear how it would
> impact the things I push for others. I pushed some patches today,
> would this mean that I'd have to look at what team/teams are involved
> (according to /etc/teams.scm.in) for each commit/series, and then
> either continue if I'm a member of that team, or skip it if I'm not?

I'm on Chris' side. We need less burden to review/push, instead of more

formal rules/obligations.

Speaking about me, I'm in the Java team, where my knowledge is best, but

in the past I also "wildered" in the Python and Ruby areas. I think

I always tried to be cautious with my reviews though: If I saw it was

just a simple version update with no dependency changes, and it

builds/runs afterwards, I gave an OK and/or pushed it, although I'm not

the super-expert. If it was too hot for me, I left my fingers from it or

asked a known expert for help.

"Teams" are a nice hint (for example, adding a tag to the bug entry),

but I wouldn't make it too formal.

Björn

-----BEGIN PGP SIGNATURE-----

iF0EAREKAB0WIQQiGUP0np8nb5SZM4K/KGy2WT5f/QUCY/+SdwAKCRC/KGy2WT5f

/YynAJsFcbXGwU1iAZ+ptVtyZjOKUDeItACeNGlD6pGb1SoIuqCEIKsrm5veS0A=

=n2hT

-----END PGP SIGNATURE-----

Christopher Baines wrote on 1 Mar 19:17 +0100

Recipients:(name . Björn Höfling)(address . bjoern.hoefling@bjoernhoefling.de)

Message-ID:87sfeouycy.fsf@cbaines.net

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes:

Toggle quote (18 lines)> On Wed, 01 Mar 2023 17:15:26 +0000
> Christopher Baines <mail@cbaines.net> wrote:
>
>> I guess I'm still a team sceptic, I think the idea is interesting and
>> I have added myself as a member of some teams. But the main impact on
>> me so far is that I've just been getting some unwanted personal email,
>> messages that previously wouldn't have landed in my inbox have been
>> doing so.
>>
>> Regarding this change specifically though, I'm unclear how it would
>> impact the things I push for others. I pushed some patches today,
>> would this mean that I'd have to look at what team/teams are involved
>> (according to /etc/teams.scm.in) for each commit/series, and then
>> either continue if I'm a member of that team, or skip it if I'm not?
>
> I'm on Chris' side. We need less burden to review/push, instead of more
> formal rules/obligations.

Identifying when you share someone's views in a discussion can be
helpful, but I don't see how taking sides is, we should all be on the
same side. Even if this is what you meant, trying to frame things
constructively is always helpful.

Ludovic Courtès wrote on 1 Mar 23:45 +0100

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

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)

Message-ID:87r0u86qgo.fsf_-_@gnu.org

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (6 lines)

> I guess I'm still a team sceptic, I think the idea is interesting and I

> have added myself as a member of some teams. But the main impact on me

> so far is that I've just been getting some unwanted personal email,

> messages that previously wouldn't have landed in my inbox have been

> doing so.

Same for me (took me a while to understand why I was suddenly Cc’d on

some many patches. :-)) I’m not sure how to improve on that.

Toggle quote (16 lines)> Regarding this change specifically though, I'm unclear how it would
> impact the things I push for others. I pushed some patches today, would
> this mean that I'd have to look at what team/teams are involved
> (according to /etc/teams.scm.in) for each commit/series, and then either
> continue if I'm a member of that team, or skip it if I'm not?
>
> If I'm going to not be pushing stuff I would have previously pushed
> because I'm not in the relevant teams, maybe I should just add myself to
> every team? I guess this is not a serious question, but I'm more making
> the point that if teams become a formal part of patch review, then some
> formalities over membership of a team is probably a prerequsite.
>
> As a point of clarification, if a patch or series touches files that
> fall within the scope of several teams, am I correct in saying that this
> change would require approval from all teams?

Good questions.

For teams like ‘core’ or ‘home’, there should be no overlap, so it’s

quite easy to see who’s in charge.

Teams related to packages are more likely to overlap, and it’s also an

area where we generally want more flexibility. The example you

give—pushing patches even though you’re not on the corresponding

team(s)—is something we’d still want to allow most of the time.

There seems to be different requirements depending on teams. I’d like

more coordination and clearer responsibilities for subsystems (guix/*,

gnu/{services,system,build}/*, etc.) and key packages/tools (Python,

ocaml-build-system, etc.). For “random packages”, I’m fine with the

status quo.

WDYT?

Thanks,

Ludo’.

Felix Lechner wrote on 1 Mar 20:21 +0100

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

Recipients:(name . Christopher Baines)(address . mail@cbaines.net)

Message-ID:CAFHYt57k-sTofs7qnhZHhc4K3N4o_T99r=QnsvaHk9upKe2yYg@mail.gmail.com

Hi,

On Wed, Mar 1, 2023 at 9:31 AM Christopher Baines <mail@cbaines.net> wrote:

Toggle quote (7 lines)

> I'm unclear how it would

> impact the things I push for others. I pushed some patches today, would

> this mean that I'd have to look at what team/teams are involved

> (according to /etc/teams.scm.in) for each commit/series, and then either

> continue if I'm a member of that team, or skip it if I'm not?

Perhaps a compromise would be to ask committers to get a second

opinion from another committer whenever they feel it is necessary.

A committer who is confident enough, however, would be encouraged to

sidestep the restriction.

This guidance would gently bump the perceived penalty for a misstep,

because ignorance was then part of the mix when an error occurred.

The second person will often be from an affected team, but sometimes

they won't. That would only need to be revisited when there was a

problem. Otherwise, it was water under the bridge.

A softer guidance would also allow the project to experiment gradually

with greater checks and balances.

After some time, the committers would be able to weigh—both

individually as well as collectively—whether the additional rules

actually provided the benefits they were designed to produce.

Kind regards

Felix Lechner

Andreas Enge wrote on 2 Mar 12:04 +0100

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

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:ZACCzGx70IiN3eIc@jurong

Hello,

in the current situation I think the suggestion is putting the horse before

the cart. In a first step before adding policy, we should make the teams

functional. While working on core-updates, I have been realising we are

already spread too thin: Some important languages have teams with one or

two members, who would effectively become bottlenecks. Other software has

no team (Qt/KDE). All in all, I also think we have too few committers.

Adding policy might completely stall the project...

If for every trivial update of a Python package we need not only submit a

patch to the bugtracker, wait for QA, get back to the patch, resign it,

push it and close the bug, but additionally wait for one of the two Python

team members to have a look at it (or let an additional week pass),

incentives to participate will tend to zero.

Your suggested policy can help against commits of too bad quality; but I

do not think this is our problem, our problem is rather a lack of fast

progress.

So I think we need to add committers, add committers to teams, encourage

teams to engage in work, and if everything works smoothly, maybe add policy.

Andreas

bokr wrote on 2 Mar 14:57 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:20230302135758.GA40729@LionPure

Hi,

tl;dr:

If you want to expand the list of committers rapidly,

would it make sense to have a sand-box repo for new committers

which trusted committers could channel cherry-picks from?

Pick your bugaboo, but I consider plausible that some

volunteering committers are there on paid job assignment

serving some agenda which you can't easily discover.

Well, that can be good and normal with FLOSS-enlightened emplayers,

but one can imagine not-so-benevolent assignments...

(pick your concept of benevolence :)

On +2023-03-02 12:04:44 +0100, Andreas Enge wrote:

Toggle quote (26 lines)> Hello,
> 
> in the current situation I think the suggestion is putting the horse before
> the cart. In a first step before adding policy, we should make the teams
> functional. While working on core-updates, I have been realising we are
> already spread too thin: Some important languages have teams with one or
> two members, who would effectively become bottlenecks. Other software has
> no team (Qt/KDE). All in all, I also think we have too few committers.
> Adding policy might completely stall the project...
> 
> If for every trivial update of a Python package we need not only submit a
> patch to the bugtracker, wait for QA, get back to the patch, resign it,
> push it and close the bug, but additionally wait for one of the two Python
> team members to have a look at it (or let an additional week pass),
> incentives to participate will tend to zero.
> 
> Your suggested policy can help against commits of too bad quality; but I
> do not think this is our problem, our problem is rather a lack of fast
> progress.
> 
> So I think we need to add committers, add committers to teams, encourage
> teams to engage in work, and if everything works smoothly, maybe add policy.
> 
> Andreas
> 
> 

--
Regards,
Bengt Richter

宋

宋文武 wrote on 3 Mar 02:08 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:87jzzywsji.fsf@envs.net

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (6 lines)

> Hello,

> in the current situation I think the suggestion is putting the horse before

> the cart. In a first step before adding policy, we should make the teams

> functional.

I find debian have various teams, and each team has a page for packages

status: https://tracker.debian.org/teams/debian-multimedia/

If we want more functional/formol teams, I think we need more tools like

this.

Maxim Cournoyer wrote on 6 Mar 16:48 +0100

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

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87h6ux285h.fsf@gmail.com

Hi Ludovic,

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

Toggle quote (33 lines)> 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

Ludovic Courtès wrote on 6 Mar 22:42 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87edq14kvu.fsf@gnu.org

Hi,

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

Toggle quote (9 lines)

> 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’.

宋

宋文武 wrote on 7 Mar 02:53 +0100

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

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87y1o9mina.fsf_-_@envs.net

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

Toggle quote (25 lines)> Hi Chris,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Regarding this change specifically though, I'm unclear how it would
>> impact the things I push for others. I pushed some patches today, would
>> this mean that I'd have to look at what team/teams are involved
>> (according to /etc/teams.scm.in) for each commit/series, and then either
>> continue if I'm a member of that team, or skip it if I'm not?
>>
>> If I'm going to not be pushing stuff I would have previously pushed
>> because I'm not in the relevant teams, maybe I should just add myself to
>> every team? I guess this is not a serious question, but I'm more making
>> the point that if teams become a formal part of patch review, then some
>> formalities over membership of a team is probably a prerequsite.
>>
> [...]
>
> Good questions.
>
> For teams like ‘core’ or ‘home’, there should be no overlap, so it’s
> quite easy to see who’s in charge.
> [...]
> For “random packages”, I’m fine with the status quo.

Hello, I'd like to know if I'm working fine according to the status

quo..

I usually push patches for others who don't have commit access, while

most packages don't have a team at all, and some with me as the only

team member.

Should I wait for another commiter's approvol under this new policy or

can I push "random packages" (eg: jwm) solo under the status quo? For

packages I as the only team member (eg: fcitx), should I looking for

another commiter for other's patches and my patches?

Thank you!

Andreas Enge wrote on 7 Mar 11:36 +0100

Recipients:(name . 宋文武)(address . iyzsong@envs.net)

Message-ID:ZAcTw6I31Rl3nRDE@jurong

Hello,

Am Tue, Mar 07, 2023 at 09:53:29AM +0800 schrieb 宋文武:

Toggle quote (8 lines)

> I usually push patches for others who don't have commit access, while

> most packages don't have a team at all, and some with me as the only

> team member.

> Should I wait for another commiter's approvol under this new policy or

> can I push "random packages" (eg: jwm) solo under the status quo? For

> packages I as the only team member (eg: fcitx), should I looking for

> another commiter for other's patches and my patches?

under the current policy, what you do is fine and very welcome. Under the
new policy, it would not be (if I remember correctly, there is a one week
waiting policy, after which one could push nevertheless).

So while the idea is good in principle, I think we would have to make sure
that first:
1) Every current and potential new package is covered by a team.
2) Every team has at least 3 members, better yet 4 or 5.
   3 members would make it possible that even if one of them is on vacation
   or otherwise busy a patch could be pushed without this additional one
   week if the other 2 agree.

And I also think we then need 3) more tooling; maybe a mailing list for each
team? A file that contains the link between source code files and teams,
and a script around "git send-email" that automatically puts into cc the
corresponding team when submitting a patch? And the feature branches with
QA on cuirass or the Guix Build Coordinator that we talked about at the
Guix Days.

I think our main problem right now is lack of committers and/or contributors.
While looking at core-updates, I was surprised how outdated some of our
packages are (around Qt, KDE and Python, for instance; I suppose it depends
a lot on the field), in particular for a rolling release distro. (For Qt@5,
we were at a release from June 2022, and there had been more recent
releases in September, October and January; it would be nice to have a
working team preparing a feature branch in a timely fashion after each
release.)

There are currently 48 committers, and not all of them are active.
I think this is just not enough for 20000 packages.

Andreas

Simon Tournier wrote on 7 Mar 13:22 +0100

Recipients:

Message-ID:861qm0da4y.fsf@gmail.com

Hi,

On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote:

Toggle quote (6 lines)

> 1) Every current and potential new package is covered by a team.

> 2) Every team has at least 3 members, better yet 4 or 5.

> 3 members would make it possible that even if one of them is on vacation

> or otherwise busy a patch could be pushed without this additional one

> week if the other 2 agree.

It would help if being committer implies appearing at least in one team,

no?

Currently in etc/teams.scm.in, I count 26 members and 20 are committers

over the 48 ones. No blame. :-)

Somehow, we have a bootstrap problem – bootstrap is everywhere. ;-)

From my understanding, Ludo’s proposal is about some structure of how

“teams“ would work and that structure would help in constituting

“teams”. One way for bootstrapping.

From my understanding, the other approach somehow proposed between the

lines in this thread would be to first constitute “teams” and then

document how they work. The other way for bootstrapping.

While I am not convinced by Ludo’s patch, I think the approach to

document first how we would like the “teams” would work is better for

bootstrapping them.

Cheers,

simon

Felix Lechner wrote on 7 Mar 16:21 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:CAFHYt54x+pjrOJK2nbN=4Q10n9LxGpOQfSHeBJ2onPoZrY7nsw@mail.gmail.com

Hi,

On Tue, Mar 7, 2023 at 2:37 AM Andreas Enge <andreas@enge.fr> wrote:

Toggle quote (5 lines)

> And the feature branches with

> QA on cuirass or the Guix Build Coordinator that we talked about at the

> Guix Days.

For what it's worth, someone turned one of my patch sets into a

proof-of-concept for feature branches. You can follow the progress via

the original patch, [1] the feature branch, [2] or the resulting CI

job set. [3]

[1] https://issues.guix.gnu.org/61989

[2] https://qa.guix.gnu.org/issue/61989

[3] https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-go-updates

Toggle quote (3 lines)

> There are currently 48 committers, and not all of them are active.

> I think this is just not enough for 20000 packages.

If a brief comparison is permitted, Debian maintains 35,000 source
packages with about a thousand voting members (aka Debian Developers)
as well as another thousand or so contributors. My estimate is that
about a third of all those people are active. On a per-package basis,
that's about fifty source packages per contributor there.

For Guix, I do not know how many committers are active or how many
people contribute without commit privileges, but assuming two hundred
active contributors altogether, I arrive at a guesstimate of about 100
packages per contributor for us.

Packaging in Guix is much simpler, however, and our collective
approach and care also reduce the pressure to be perfect. (In Guix,
the "perfect" sentiment only survives in the formattin of commit
messages.) Debian's celebrity status among software distributions also
attracts a lot of people.

As a side note, the growth of a group can lead to greater social
tensions and a proliferation of outside politics. Given the excellent
stewardship in Guix to date and the technical possibilities of
automatic patch approval, I am therefore not necessarily in favor of
growing the contributor base at all costs.

We really have something special in Guix. Thank you all for your hard
work and mutual friendship!

Kind regards,
Felix Lechner

Maxim Cournoyer wrote on 7 Mar 19:29 +0100

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87sfegwh28.fsf@gmail.com

Hi Simon,

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

Toggle quote (16 lines)> Hi,
>
> On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote:
>
>> 1) Every current and potential new package is covered by a team.
>> 2) Every team has at least 3 members, better yet 4 or 5.
>>    3 members would make it possible that even if one of them is on vacation
>>    or otherwise busy a patch could be pushed without this additional one
>>    week if the other 2 agree.
>
> It would help if being committer implies appearing at least in one team,
> no?
>
> Currently in etc/teams.scm.in, I count 26 members and 20 are committers
> over the 48 ones.  No blame. :-)

If most committers end up being team members, aren't we back to where we
currently stand?  It seems the original motivation here is to add some
extra control/guards against undesirable commits landing in the core of
Guix.  If a committer that previously landed such commits joined the
core team (e.g., myself), it seems to me the situation would be little
changed:

1. Our pool of reviewers would likely continue to be spread too thin.

2. The 2 weeks time window would quickly slip, even with a team looking
at a more focused backlog, or the reviews would only be of the kind "I
think that's not what we want" without more time or energy to offer the
kind of concrete insights that can be turned into action for the
submitter.

3. The team member might be tempted to take their chance and merge their
change with little to no feedback, or feedback they perceived
insufficient or not actionable enough to justify keeping their
submission in limbo for longer.

I think the main problem we have is social, not organizational.  There's
little incentive to jump into the laborious review process compared to
hack on something we like in our free time.  We need to promote and
value review work more, without making it feel like a compulsory chore.
That's a great challenge to solve for a project that's driven by
volunteers.

I'll venture a suggestion to explore: adding enticements to review (some
playful guidelines such as "while waiting for your 2 weeks review
period, please try to review twice as many other submissions that have
been patiently waiting on the patches tracker :-)", or some stats
crunched and advertised periodically to guix-devel or even our to our
blog about our top reviewers, etc.).

-- 
Maxim

Leo Famulari wrote on 7 Mar 23:40 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:ZAe9arZFiCihLH7o@jasmine.lan

I don't have a strong opinion one way or the other about whether we

should formalize the review process. The status quo isn't working well,

so I'm in favor of trying something.

On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:

Toggle quote (7 lines)

> I think the main problem we have is social, not organizational. There's

> little incentive to jump into the laborious review process compared to

> hack on something we like in our free time. We need to promote and

> value review work more, without making it feel like a compulsory chore.

> That's a great challenge to solve for a project that's driven by

> volunteers.

However, I agree with this point wholeheartedly. We really need to ask

ourselves, why would anyone review patches? It's a lot of work, often

thankless, and unfortunately sometimes unpleasant.

Toggle quote (7 lines)

> I'll venture a suggestion to explore: adding enticements to review (some

> playful guidelines such as "while waiting for your 2 weeks review

> period, please try to review twice as many other submissions that have

> been patiently waiting on the patches tracker :-)", or some stats

> crunched and advertised periodically to guix-devel or even our to our

> blog about our top reviewers, etc.).

In release announcements, alongside to the the normal `git shortlog`

list of authors, I suggest also publicizing the list of committers:

`git shortlog --numbered --summary --committer v1.4.0..HEAD`

A small thing, but hopefully one of many incentives to review and

commit.

Efraim Flashner wrote on 8 Mar 10:12 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:ZAhRg7BjytZGGB5O@3900XT

On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:

Toggle quote (27 lines)> Hi Simon,
> 
> Simon Tournier <zimon.toutoune@gmail.com> writes:
> 
> > Hi,
> >
> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote:
> >
> >> 1) Every current and potential new package is covered by a team.
> >> 2) Every team has at least 3 members, better yet 4 or 5.
> >>    3 members would make it possible that even if one of them is on vacation
> >>    or otherwise busy a patch could be pushed without this additional one
> >>    week if the other 2 agree.
> >
> > It would help if being committer implies appearing at least in one team,
> > no?
> >
> > Currently in etc/teams.scm.in, I count 26 members and 20 are committers
> > over the 48 ones.  No blame. :-)
> 
> If most committers end up being team members, aren't we back to where we
> currently stand?  It seems the original motivation here is to add some
> extra control/guards against undesirable commits landing in the core of
> Guix.  If a committer that previously landed such commits joined the
> core team (e.g., myself), it seems to me the situation would be little
> changed:

My understanding was that it would help people feel more ownership over
a portion of the code, allowing others to tag them explicitly for code
review touching their area of expertise and allowing them to perhaps
"pay less attention" to areas where they are less sure. The second part
works better when all areas are covered by a team, but in practice I
feel it was already happening, judging by our large backlog of patches.

Toggle quote (30 lines)> 1. Our pool of reviewers would likely continue to be spread too thin.
> 
> 2. The 2 weeks time window would quickly slip, even with a team looking
> at a more focused backlog, or the reviews would only be of the kind "I
> think that's not what we want" without more time or energy to offer the
> kind of concrete insights that can be turned into action for the
> submitter.
> 
> 3. The team member might be tempted to take their chance and merge their
> change with little to no feedback, or feedback they perceived
> insufficient or not actionable enough to justify keeping their
> submission in limbo for longer.
> 
> I think the main problem we have is social, not organizational.  There's
> little incentive to jump into the laborious review process compared to
> hack on something we like in our free time.  We need to promote and
> value review work more, without making it feel like a compulsory chore.
> That's a great challenge to solve for a project that's driven by
> volunteers.
> 
> I'll venture a suggestion to explore: adding enticements to review (some
> playful guidelines such as "while waiting for your 2 weeks review
> period, please try to review twice as many other submissions that have
> been patiently waiting on the patches tracker :-)", or some stats
> crunched and advertised periodically to guix-devel or even our to our
> blog about our top reviewers, etc.).
> 
> -- 
> Maxim

-- 
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

Maxim Cournoyer wrote on 8 Mar 18:05 +0100

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:878rg7uqb4.fsf@gmail.com

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

Toggle quote (35 lines)> On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
>> Hi Simon,
>> 
>> Simon Tournier <zimon.toutoune@gmail.com> writes:
>> 
>> > Hi,
>> >
>> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote:
>> >
>> >> 1) Every current and potential new package is covered by a team.
>> >> 2) Every team has at least 3 members, better yet 4 or 5.
>> >>    3 members would make it possible that even if one of them is on vacation
>> >>    or otherwise busy a patch could be pushed without this additional one
>> >>    week if the other 2 agree.
>> >
>> > It would help if being committer implies appearing at least in one team,
>> > no?
>> >
>> > Currently in etc/teams.scm.in, I count 26 members and 20 are committers
>> > over the 48 ones.  No blame. :-)
>> 
>> If most committers end up being team members, aren't we back to where we
>> currently stand?  It seems the original motivation here is to add some
>> extra control/guards against undesirable commits landing in the core of
>> Guix.  If a committer that previously landed such commits joined the
>> core team (e.g., myself), it seems to me the situation would be little
>> changed:
>
> My understanding was that it would help people feel more ownership over
> a portion of the code, allowing others to tag them explicitly for code
> review touching their area of expertise and allowing them to perhaps
> "pay less attention" to areas where they are less sure. The second part
> works better when all areas are covered by a team, but in practice I
> feel it was already happening, judging by our large backlog of patches.

I believe that's the original rationale behind teams.  But the change
being discussed here proposes to add a policy to make teams the
governing body of changes that touch their area (gating the patches
applied), which is something else.  That alone sounds like a good idea,
assuming teams are healthy and functional.  But the aim of the proposed
change is to reducing friction between committers, or "pacifying"
collaboration, to quote the original message.  I don't think such policy
will help *much* in that regard, since most of the teams people are the
same people as the committers.  It'll help some in the sense the group
interacting together on merging patches will be smaller, but at the cost
of reduced throughput, I reckon.

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.

-- 
Thanks,
Maxim

Maxim Cournoyer wrote on 8 Mar 19:58 +0100

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:874jqvul1v.fsf@gmail.com

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

[...]

Toggle quote (8 lines)

> In release announcements, alongside to the the normal `git shortlog`

> list of authors, I suggest also publicizing the list of committers:

> `git shortlog --numbered --summary --committer v1.4.0..HEAD`

> A small thing, but hopefully one of many incentives to review and

> commit.

Seems an easy thing to do; but in the context of this discussion we'd
like to emphasizes the reviewers rather than just the committers
(otherwise Ricardo would always appear at the top, thanks to the sheer
number of their R package updates (thanks!)).  It seems starting to use
the 'Reviewed-by' git message tag would make this easy to account for.

-- 
Thanks,
Maxim

Vagrant Cascadian wrote on 9 Mar 00:38 +0100

Recipients:

Message-ID:87sfeeg6fk.fsf@yucca

On 2023-03-08, Maxim Cournoyer wrote:

Toggle quote (6 lines)

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

I have been watching this thread with great curiosity for exactly this

reason!

One of the things I like about Guix, coming from a couple decades of

involvement with Debian, is the lack of package "ownership" ... in

Debian, any Debian Developer with upload rights can technically upload

any package, but it is considered inappropriate to do so without

following various processes. Over the years, ways to opt-in to

streamlined processes now exist, but the norm is still very much package

"ownership".

Guix is starting from a much more flexible model, but struggling with

challenges of scale ... a small number of people maintaining a huge

number of packages.

I am a bit concerned that formalizing this much process for teams just

yet...

There is not much granularity of team scope and responsibilities. The

current teams implementation seems to involve claiming one or more

gnu/packages/*.scm files (or other files)... but not individual packages

or groups of packages within one of those. It seems quite rough around

the edges and I am concerned about how it will play out to further

formalize the process.

I almost wonder if it wouldn't be good to spell out what exactly is

desired to be accomplished by having teams? Maybe much of that

conversation has already happened, but ... spelling it out first, and

then trying to come up with implementation details that attempt to fit

the goals?

I have a hunch that this dish might benefit from a bit more seasoning. I

am not sure exactly which herbs and spices to reach for, or how long to

leave it simmering on the stove... but I know people are getting hungry!

live well,

vagrant

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZAkcbwAKCRDcUY/If5cW

qmHJAP9bADxJJnp4Yfb83jTKQqBynGhPshg7AZKhDNC/o5HEZAD/UUXpuQKaOSrq

gr3i3eSV40gpVWsxXO0/uH5V4uMY7QY=

=HNIA

-----END PGP SIGNATURE-----

Maxim Cournoyer wrote on 9 Mar 06:12 +0100

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)

Message-ID:87pm9itsnl.fsf@gmail.com

Hi,

Vagrant Cascadian <vagrant@debian.org> writes:

[...]

Toggle quote (6 lines)

> I almost wonder if it wouldn't be good to spell out what exactly is

> desired to be accomplished by having teams? Maybe much of that

> conversation has already happened, but ... spelling it out first, and

> then trying to come up with implementation details that attempt to fit

> the goals?

I believe the original goal of teams was to offer a more focus stream of
patches to review for those adhering to a specific team.  I'll let the
implementers of teams.scm correct me if I got that wrong :-).

-- 
Thanks,
Maxim

Simon Tournier wrote on 9 Mar 09:48 +0100

Recipients:

Message-ID:86v8janwdm.fsf@gmail.com

Hi,

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

Toggle quote (3 lines)

> number of their R package updates (thanks!)). It seems starting to use

> the 'Reviewed-by' git message tag would make this easy to account for.

Quoting from thread [1]:

I agree that Reviewed-by would be helpful.

Once reviewed, the author or the reviewer could roll the count and

re-send the patch (or series), applying the line Reviewed-by.

It would reward the reviewer for their work. And it would help the

committer work.

1: https://yhetil.org/guix/86k00avhpv.fsf@gmail.com

Cheers,

simon

Simon Tournier wrote on 9 Mar 10:46 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:86lek6ntpb.fsf@gmail.com

Hi Maxim,

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

Toggle quote (6 lines)

> 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/

Maxim Cournoyer wrote on 10 Mar 05:36 +0100

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:874jqtte7c.fsf@gmail.com

Hi Simon et al.,

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

Toggle quote (19 lines)> 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.

Apologies for starting a tangent (which is interesting in its own!).

Rewinding to the beginning, I believe the novelty proposed in this patch

is (quoting the original message):

Toggle quote (4 lines)

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

In other words, to give teams the power to gate the changes touching

their scope. That's reasonable, if we have functional teams. I'd argue

we aren't there yet. And also:

Toggle quote (3 lines)

> I think it avoids the unavoidable misunderstandings that can arise in

> a growing group and help pacify day-to-day collaboration.

Again, "pacify" irks me a bit in this sentence, given I consider
collaboration has and continues to be cordial in our community, unless
I've been living under a rock.

-- 
Thanks,
Maxim

Andreas Enge wrote on 10 Mar 15:19 +0100

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:ZAs8jT4wkjJJ6xPV@jurong

Hello Simon,

Am Thu, Mar 09, 2023 at 10:46:08AM +0100 schrieb Simon Tournier:

Toggle quote (3 lines)

> Hierarchy already exists, as in any social group, as in any group of

> people collaborating. The hierarchy is currently informal.

while I am sensitive to your argument about privileges, I am afraid that
the suggestion would remove privileges from the committers, while not
bestowing them on anybody else; as a result, everybody would be worse off
than before. Right now one out of the (let us be pessimistic) 20 active
committers can push any patch from the issue tracker, say for a package
trivially obtained via "guix import pypi ...". With the suggested change,
the currently 1 (and in future hopefully one out of a few) members of the
python group will have to approve the patch. In that situation, there is
no incentive for anybody else to even look at the patch (without agency,
why would one bother?), and we will effectively have split the Guix project
into a collection of walled gardens.

I think this suggestion has the potential to make a stuttering project
grind to a complete halt. And I am afraid that we are on a track to
replacing joy, agency and community by grind and bureaucracy.

I suggest to close this issue due to a weak consensus against the proposal
(or at least the lack of a clear consensus for it).

Andreas

Ludovic Courtès wrote on 10 Mar 18:22 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87bkl0frnk.fsf@gnu.org

Hello Maxim and all!

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

Toggle quote (8 lines)

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

> In other words, to give teams the power to gate the changes touching

> their scope. That's reasonable, if we have functional teams. I'd argue

> we aren't there yet.

I kinda agree; bootstrapping issue then?

I hope the maintainer team can help make teams “more functional”,

whatever that teams. It’s really what maintainership is about in Guix;

it’s not about writing code.

Toggle quote (8 lines)

> And also:

>> I think it avoids the unavoidable misunderstandings that can arise in

>> a growing group and help pacify day-to-day collaboration.

> Again, "pacify" irks me a bit in this sentence, given I consider

> collaboration has and continues to be cordial in our community, unless

> I've been living under a rock.

“Pacify” in the sense that, by being explicit, we avoid

misunderstandings that could turn into unpleasant experiences.

Like you I’m glad collaboration is nice and friendly; yet, over the past

few months I’ve experienced misunderstandings that seemingly broke the

consensus-based process that has always prevailed.

In a way, that’s probably bound to happen as the group grows, and I

think that’s why we must be explicit about what the process is and about

whether one is expressing consent or dissent.

With so many things happening in Guix (yay!), it’s also easy to overlook

a change and realize when it’s too late. By having a rule that at least

one other person on the team must approve (consent to) a change, we

reduce that risk.

Being on a team, then, is a way to express interest on a topic and to be

“in the loop”. It is not about asserting power or building a hierarchy;

it’s about formalizing existing relations and processes.

I hope this clarifies my position!

Ludo’.

Simon Tournier wrote on 10 Mar 18:33 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:87ilf8mry1.fsf@gmail.com

Hi Andreas,

Re-reading the thread, I think we started with different frames. :-)

On ven., 10 mars 2023 at 15:19, Andreas Enge <andreas@enge.fr> wrote:

Toggle quote (12 lines)> while I am sensitive to your argument about privileges, I am afraid that
> the suggestion would remove privileges from the committers, while not
> bestowing them on anybody else; as a result, everybody would be worse off
> than before. Right now one out of the (let us be pessimistic) 20 active
> committers can push any patch from the issue tracker, say for a package
> trivially obtained via "guix import pypi ...". With the suggested change,
> the currently 1 (and in future hopefully one out of a few) members of the
> python group will have to approve the patch. In that situation, there is
> no incentive for anybody else to even look at the patch (without agency,
> why would one bother?), and we will effectively have split the Guix project
> into a collection of walled gardens.

What you are pointing is that not all the teams are willing to

collaborate the same way. For sure I agree that updating a leaf package

does not require any more extra work – processing the submission by the

committer is already enough boring work.

However, for some packages or changes, the impact is far from being

trivial. I have in mind many changes that happen aside gnu/packages and

also some core packages (Guile, etc.).

For these kind of changes, it does not appear to me so crazy to ask more

than the submitter or committer eyes. For instance, one can read from

recent messages,

this "trivial" patch implies a Julia (almost) world rebuild --

so potentially some breakages. And personally, I cannot run

again and again after broken packages from unrelated

changes. :-)

To be clear, it’s time-consuming and stressful. That’s not sane and I’d

rather not work that way.

https://yhetil.org/guix/CAJ3okZ3j+HTATsoGE978b+LGk0KAEM7-BAGSy_Gtm61FzTWwQA@mail.gmail.com

https://yhetil.org/guix/87cz5qyv10.fsf@gnu.org

The wording of the patch is misleading but, I guess, the intent is to

smooth these kind of situations.

For sure, QA is helping a lot but there is still limitations. Consider

this thread [1] about updating Git. We do not have the capacity to let

QA check that all is fine. Again considering [1], it appears to me

reasonable to ask that more than two people (Greg and I) give a look,

thus this thread [1] appears to me sane.

For some changes aside packages, QA is helpless. Yeah we can improve

the Guix test suite and increase the coverage. But still, for some

changes, the collateral effect is often hard to evaluate. Hence, ask

for another look to be considered as green light appears to me fine.

I guess that the intent of this patch #61894 and I agree that the

wording is probably poor for that intent. :-)

Well, instead of closing, I think this patch requires an update.

Since Guix is growing and that’s a good thing, it implies two things:

(a) that more people are relying on it so for some part we need less

unexpected breakage and (b) that some implicit that worked until now

needs to be more explicit.

Yeah, the corollary of (a) is moving less fast for some part. But there

is no free lunch. ;-)

And (b) does not mean strong all white or all black.

Cheers,

simon

1: https://yhetil.org/guix/20230217180402.29401-1-code@greghogan.com/#r

Felix Lechner wrote on 10 Mar 19:22 +0100

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:CAFHYt565J8w1Rr59cW85xCBCA6nq+_0rA9z-UHtaSATfgdRnWg@mail.gmail.com

Hi Ludo',

On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)

> Like you I’m glad collaboration is nice and friendly; yet, over the past

> few months I’ve experienced misunderstandings that seemingly broke the

> consensus-based process that has always prevailed.

I have no idea what happened there, but it may be best to be open and

direct about it. Would it be helpful for everyone to share details?

Although you know that already, it would be best to avoid accusations

and look inward with statements like "I was unhappy about ... because

of ...." I might also avoid the word "you" and instead address all

messages to a third party.

When unhappy, we could write to "Yogi Bear". Alternatives would be

"Scooby-Doo" or "Winnie the Poo".

They do something similar in the parliaments around the world.

I picked unisex characters for that reason (although all three appear

a bit more male than female).

Also, why not retitle the bug as "Restore and improve our

consensus-based process"?

Thanks to everyone for working on Guix! We have a truly great, warm

and welcoming community.

Kind regards

Felix

Andreas Enge wrote on 11 Mar 00:19 +0100

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:ZAu65VR4Nxo7Efys@jurong

Am Fri, Mar 10, 2023 at 06:33:58PM +0100 schrieb Simon Tournier:

Toggle quote (6 lines)

> However, for some packages or changes, the impact is far from being

> trivial. I have in mind many changes that happen aside gnu/packages and

> also some core packages (Guile, etc.).

> For these kind of changes, it does not appear to me so crazy to ask more

> than the submitter or committer eyes.

That is true! So far, this has been handled by common sense of the people

working on a patch (and sometimes that process then fails).

Toggle quote (3 lines)

> (b) that some implicit that worked until now needs to be more explicit.

> And (b) does not mean strong all white or all black.

In the longer run I also agree with (b). But I am not sure it will be easy
to formulate a rule that captures well the intended policy and draws the
line between "trivial", anybody can push any time, and "complex", where more
opinions are needed, and maybe stages in between. It may be worth the trial.

Andreas

Simon Tournier wrote on 11 Mar 14:20 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:86356bbf0x.fsf@gmail.com

Hi,

On Sat, 11 Mar 2023 at 00:19, Andreas Enge <andreas@enge.fr> wrote:

Toggle quote (5 lines)

> In the longer run I also agree with (b). But I am not sure it will be easy

> to formulate a rule that captures well the intended policy and draws the

> line between "trivial", anybody can push any time, and "complex", where more

> opinions are needed, and maybe stages in between. It may be worth the trial.

I agree. How to find the right balance between no guard and too many

stones if not rocks crossing the path?

Cheers,

simon

Maxim Cournoyer wrote on 12 Mar 03:33 +0100

Recipients:(name . Felix Lechner)(address . felix.lechner@lease-up.com)

Message-ID:878rg2r95i.fsf@gmail.com

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

Toggle quote (11 lines)> Hi Ludo',
>
> On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>> few months I’ve experienced misunderstandings that seemingly broke the
>> consensus-based process that has always prevailed.
>
> I have no idea what happened there, but it may be best to be open and
> direct about it. Would it be helpful for everyone to share details?

It may help to shed a bit of light on the original reason I think this
change came into existence, and in the interest of transparency and
hopefully improving or finding alternatives to the proposed change, I
consent to Ludovic openly discussing it, even if it involves a healthy
dose of critique and looking inward.

Toggle quote (5 lines)

> Although you know that already, it would be best to avoid accusations

> and look inward with statements like "I was unhappy about ... because

> of ...." I might also avoid the word "you" and instead address all

> messages to a third party.

[...]

Toggle quote (3 lines)

> Also, why not retitle the bug as "Restore and improve our

> consensus-based process"?

I think this captures well what one of the issues I see with this
change: it seems to be an attempt to resolve a local conflict (?) by
apply a new global policy (which could be OK if the problem was
widespread, but I doubt it is?), making everyone pay for it (via added
bureaucracy).

I've also pointed that if this is what it's trying to fix, it won't
really help, since policy is not a substitute to consensus, and we're
the same pool of people who will need to get along, whether as
committers or as members of the same team.

-- 
Thanks,
Maxim

Maxim Cournoyer wrote on 12 Mar 04:26 +0100

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87356ar6p1.fsf@gmail.com

Hi Ludovic,

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

Toggle quote (14 lines)> Hello Maxim and all!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> 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.
>>
>> In other words, to give teams the power to gate the changes touching
>> their scope.  That's reasonable, if we have functional teams.  I'd argue
>> we aren't there yet.
>
> I kinda agree; bootstrapping issue then?

Bootstrapping, yes, but also tooling, and people not yet catching up.

As I've pointed before, we've had the doc mentioning a command which

doesn't work to notify teams since at least October of last year [0] and

it seems few people even noticed (I think you only did recently :-)),

which tells me it's not a very well-trodden path yet!

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

Toggle quote (4 lines)

> I hope the maintainer team can help make teams “more functional”,

> whatever that teams. It’s really what maintainership is about in Guix;

> it’s not about writing code.

I'm happy to help with the effort, but I don't think it's particularly

relevant to Guix co-maintainers more than anyone else interested in

advancing/contributing to Guix, and I find it great that it's this way

(not out of laziness, but because the talent pool of the whole Guix

community is much larger that that of us 4 co-maintainers). Per what we

co-maintainers signed up for in [1], the co-maintainers three primary

duties are:

Enforcing GNU and Guix policies, such as the project’s commitment to

be released under a copyleft free software license (GPLv3+) and to

follow the Free System Distribution Guideline (FSDG).

Enforcing our code of conduct: maintainers are the contact point for

anyone who wants to report abuse.

Making decisions, about code or anything, when consensus cannot be

reached. We’ve probably never encountered such a situation before,

though!

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

Toggle quote (15 lines)>> And also:
>>> I think it avoids the unavoidable misunderstandings that can arise in
>>> a growing group and help pacify day-to-day collaboration.
>>
>> Again, "pacify" irks me a bit in this sentence, given I consider
>> collaboration has and continues to be cordial in our community, unless
>> I've been living under a rock.
>
> “Pacify” in the sense that, by being explicit, we avoid
> misunderstandings that could turn into unpleasant experiences.
>
> Like you I’m glad collaboration is nice and friendly; yet, over the past
> few months I’ve experienced misunderstandings that seemingly broke the
> consensus-based process that has always prevailed.

I'm sorry that you feel that way.  I don't think consensus was willfully
broken, and perhaps by studying some actual examples of these
occurrences we can better understand what went wrong and how the new
suggested policy would have helped or could be modified to help avoid
such problems in the future.  It's also worth noting that this
consensus-based process has always been implicit; for example, it is not
defined/mentioned anywhere in our documentation.  Perhaps it should?

Toggle quote (12 lines)> In a way, that’s probably bound to happen as the group grows, and I
> think that’s why we must be explicit about what the process is and about
> whether one is expressing consent or dissent.
>
> With so many things happening in Guix (yay!), it’s also easy to overlook
> a change and realize when it’s too late.  By having a rule that at least
> one other person on the team must approve (consent to) a change, we
> reduce that risk.
>
> Being on a team, then, is a way to express interest on a topic and to be
> “in the loop”.

That's already what teams can do!  I'd argue giving them the extra
powers that would be conferred to teams in this is not needed/desirable.
Some committer not a regular member of X team may still be confident
enough to push a patch sitting on the tracker, and I think they should
be able to.

Toggle quote (3 lines)

> It is not about asserting power or building a hierarchy;

> it’s about formalizing existing relations and processes.

OK; I think in practice it would amount to that though (building a

hierarchy which has some form power).

Toggle quote (2 lines)

> I hope this clarifies my position!

Yes, it does.  Thanks for taking the time to field some of the
questions!

-- 
Thanks,
Maxim

Simon Tournier wrote on 12 Mar 12:14 +0100

Recipients:

Message-ID:86bkky9q6r.fsf@gmail.com

Hi,

On Sat, 11 Mar 2023 at 21:33, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (6 lines)

> It may help to shed a bit of light on the original reason I think this

> change came into existence, and in the interest of transparency and

> hopefully improving or finding alternatives to the proposed change, I

> consent to Ludovic openly discussing it, even if it involves a healthy

> dose of critique and looking inward.

There is no one original reason but several diffuse situations. Well, I

have tried to provide the context and the intent behind the patch in

this message here:

https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00121.html

Although I agree that the wording of the initial Ludo’s proposal is not

the one I would like, it does not appear to me so crazy to ask another

LGTM for some part of the code.

Double-check leaf Python package is not worth and it adds a lot of

unnecessary burden. We all agree here, I guess.

Double-check core packages or Guile build-side code sounds to me totally

reasonable.

The initial wording of the proposal,

Toggle snippet (5 lines)

+When your patch falls under the area of expertise of a team

+(@pxref{Teams}), you need the explicit approval of at least one team

+member before committing (another team member if you are on the team).

cannot apply for all the teams. Again, we all agree I guess.

However, this proposal appears to me totally sane for what is under the

scope of the team named ’core’ for instance.

Instead of a strong opposition, the patch needs an update.

Cheers,

simon

Andreas Enge wrote on 12 Mar 12:52 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:ZA284rQzrILBLDhv@jurong

Hello,

Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:

Toggle quote (12 lines)> Ludovic Courtès <ludo@gnu.org> writes:
> > I hope the maintainer team can help make teams “more functional”,
> > whatever that teams.  It’s really what maintainership is about in Guix;
> > it’s not about writing code.
> I'm happy to help with the effort, but I don't think it's particularly
> relevant to Guix co-maintainers more than anyone else interested in
> advancing/contributing to Guix, and I find it great that it's this way
> (not out of laziness, but because the talent pool of the whole Guix
> community is much larger that that of us 4 co-maintainers).  Per what we
> co-maintainers signed up for in [1], the co-maintainers three primary
> duties are:

but there is also
"Looking after people: making sure to promote people who are very involved
in leadership position; dubbing new committers, new maintainers, new
members of the spending committee. Supporting new initiatives. Generally
trying to make sure everyone’s happy. :-)"

As for all "management positions" (even if we may not like the term here
as it often evokes a hierarchy; maybe "board members of a non-profit"
captures the idea better), I think the maintainers' role is more about
moderating ("animer" in French, which I think is more to the point),
keeping the overview, overseeing and facilitating initiatives, making sure
the project moves on, etc., than day to day work on details, or the three
technical points you mention (and which probably hardly ever require
action).

Maybe it would be time to move on to something like the Debian Social
Contract and concrete rules how membership, commit rights, maintainer
roles in the Guix project are bestowed and what is expected from people
fulfilling such roles.

Andreas

Simon Tournier wrote on 12 Mar 13:25 +0100

Recipients:

Message-ID:867cvm17ho.fsf@gmail.com

Hi Maxim,

On Sat, 11 Mar 2023 at 22:26, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (6 lines)

> I'm sorry that you feel that way. I don't think consensus was willfully

> broken, and perhaps by studying some actual examples of these

> occurrences we can better understand what went wrong and how the new

> suggested policy would have helped or could be modified to help avoid

> such problems in the future.

Well, all is in the public archive. :-) For one recent example, see

#61255 [1]:

Toggle snippet (8 lines)

We should think about how to improve our processes to avoid such issues

in the future. I did raise concerns about this very patch late at night

during FOSDEM, 24h after submission, and reaffirmed my viewpoint days

later. I understand that delaying a nice patch series like this one is

unpleasant, but I think those concerns should have been taken into

account.

1: https://issues.guix.gnu.org/issue/61255#32

From my point of view, it is useless to rehash specific example by

specific example. Because it is not one unique case but several diffuse

situations popping here or there.

To be honest, I am missing what are the objections when one is asking to

double-check some core changes.

Anyway, I have expressed my opinion in various places in this thread and

now I will not comment further.

Cheers,

simon

Maxim Cournoyer wrote on 13 Mar 01:08 +0100

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:87zg8ho6my.fsf@gmail.com

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (21 lines)> Hello,
>
> Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:
>> Ludovic Courtès <ludo@gnu.org> writes:
>> > I hope the maintainer team can help make teams “more functional”,
>> > whatever that teams.  It’s really what maintainership is about in Guix;
>> > it’s not about writing code.
>> I'm happy to help with the effort, but I don't think it's particularly
>> relevant to Guix co-maintainers more than anyone else interested in
>> advancing/contributing to Guix, and I find it great that it's this way
>> (not out of laziness, but because the talent pool of the whole Guix
>> community is much larger that that of us 4 co-maintainers).  Per what we
>> co-maintainers signed up for in [1], the co-maintainers three primary
>> duties are:
>
> but there is also
> "Looking after people: making sure to promote people who are very involved
> in leadership position; dubbing new committers, new maintainers, new
> members of the spending committee. Supporting new initiatives. Generally
> trying to make sure everyone’s happy. :-)"

Yes, I've only quoted the core duties of the maintainers, because we
struggle to do much of anything else; thankfully, many individuals in
the our community mostly fill in the gaps (thanks!).  I'm aware that
ideally we would do more: if you are interested in giving a hand, let
guix-maintainers know -- we're currently 4 and could do with a 5th
person onboard to smooth out operations).

Toggle quote (9 lines)

> As for all "management positions" (even if we may not like the term here

> as it often evokes a hierarchy; maybe "board members of a non-profit"

> captures the idea better), I think the maintainers' role is more about

> moderating ("animer" in French, which I think is more to the point),

> keeping the overview, overseeing and facilitating initiatives, making sure

> the project moves on, etc., than day to day work on details, or the three

> technical points you mention (and which probably hardly ever require

> action).

Past maintainers will probably smile at the "hardly ever require
actions" :-). But you are right, the occurrences of things like CoC
complaints or other requests sent over email are not constant in time
(but it doesn't mean they are easy or quick to resolve).  That said, I
agree with the general idea about maintainers having a role to play in
smoothing out interactions (which I believe we are doing) and
shepherding efforts toward a common goal (which I don't think we are
doing much at all).

Toggle quote (5 lines)

> Maybe it would be time to move on to something like the Debian Social

> Contract and concrete rules how membership, commit rights, maintainer

> roles in the Guix project are bestowed and what is expected from

> people fulfilling such roles.

I'm not sure how something like the Debian Social Contract would help
here, and I do not know that "membership" has a meaning in our
community.  As I mentioned before, I feel like our problems are mostly
social rather than organizational (such as the question about how to
motivate people to review more), so I'd rather focusing on that more
than adding organizational layers.

I'll now leave the discussion space to other participants, as I feel
like I've already used too much of it :-).

-- 
Thanks,
Maxim

Ludovic Courtès wrote on 15 Mar 17:08 +0100

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87bkku2e14.fsf@gnu.org

Hello!

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

[...]

Toggle quote (10 lines)>> “Pacify” in the sense that, by being explicit, we avoid
>> misunderstandings that could turn into unpleasant experiences.
>>
>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>> few months I’ve experienced misunderstandings that seemingly broke the
>> consensus-based process that has always prevailed.
>
> I'm sorry that you feel that way.  I don't think consensus was willfully
> broken,

That’s my point: by being explicit about approval, we would avoid such

misunderstandings.

Toggle quote (5 lines)

> and perhaps by studying some actual examples of these occurrences we

> can better understand what went wrong and how the new suggested policy

> would have helped or could be modified to help avoid such problems in

> the future.

I don’t want to rehash past occurrences of this problem. It boils down

to: changes where pushed despite consensus evidently not being met, at

least not in the mind of every involved party.

To some extent, that’s bound to happen due to an increase of the number

of contributors, scope of the project, and diversity of backgrounds. By

making it clear that lack of “LGTM” from another team member equates

with lack of consensus, we would avoid those misunderstandings.

A good reference on consensus-based decision making is

https://www.seedsforchange.org.uk/consensus.

Toggle quote (4 lines)

> It's also worth noting that this consensus-based process has always

> been implicit; for example, it is not defined/mentioned anywhere in

> our documentation. Perhaps it should?

Those who’ve followed the project long enough, such as part of the

current maintainer collective, are certainly aware of that; it’s also

spelled out in

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

That said, again in the spirit of improving legibility, writing it down

would be much welcome.

Toggle quote (14 lines)>> In a way, that’s probably bound to happen as the group grows, and I
>> think that’s why we must be explicit about what the process is and about
>> whether one is expressing consent or dissent.
>>
>> With so many things happening in Guix (yay!), it’s also easy to overlook
>> a change and realize when it’s too late.  By having a rule that at least
>> one other person on the team must approve (consent to) a change, we
>> reduce that risk.
>>
>> Being on a team, then, is a way to express interest on a topic and to be
>> “in the loop”.
>
> That's already what teams can do!

Yes and no. With the amount of activity going on, it’s easy to overlook

something. The explicit synchronization point could mitigate that.

Toggle quote (5 lines)

> I'd argue giving them the extra powers that would be conferred to

> teams in this is not needed/desirable. Some committer not a regular

> member of X team may still be confident enough to push a patch sitting

> on the tracker, and I think they should be able to.

Self-assessment becomes tricky that this scale; I might be confident and

yet someone will point out a problem (that literally happened to me two

days ago in https://issues.guix.gnu.org/62062). That’s when review

really helps.

For “core” work, I insist that explicit approval (and thus peer review)

is necessary. I doubt anyone would seriously challenge that.

Now, I agree, as I wrote before, that this may be overkill for “random

packages”.

Thus we need to find the right balance.

What about team/scope-specific rules? As in: “Changes covered by teams

X, Y, and Z need to be explicitly approved by at least one other member

of the team.”

Toggle quote (6 lines)

>> It is not about asserting power or building a hierarchy;

>> it’s about formalizing existing relations and processes.

> OK; I think in practice it would amount to that though (building a

> hierarchy which has some form power).

I disagree: just because power relations are not spelled out doesn’t
mean they don’t exist.  I don’t know where you’re talking from; one
thing that to me shed light on these matters is “The Tyranny of
Structurelessness” (I’m sure I mentioned it before, I certainly did
during Q&A on this very topic at the Ten Years event; apologies if I
sound like a broken record!).

Thanks,
Ludo’.

Maxim Cournoyer wrote on 17 Mar 16:46 +0100

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:875yaz7544.fsf@gmail.com

Hi Ludovic,

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

Toggle quote (33 lines)> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
> [...]
>
>>> “Pacify” in the sense that, by being explicit, we avoid
>>> misunderstandings that could turn into unpleasant experiences.
>>>
>>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>>> few months I’ve experienced misunderstandings that seemingly broke the
>>> consensus-based process that has always prevailed.
>>
>> I'm sorry that you feel that way.  I don't think consensus was willfully
>> broken,
>
> That’s my point: by being explicit about approval, we would avoid such
> misunderstandings.
>
>> and perhaps by studying some actual examples of these occurrences we
>> can better understand what went wrong and how the new suggested policy
>> would have helped or could be modified to help avoid such problems in
>> the future.
>
> I don’t want to rehash past occurrences of this problem.  It boils down
> to: changes where pushed despite consensus evidently not being met, at
> least not in the mind of every involved party.
>
> To some extent, that’s bound to happen due to an increase of the number
> of contributors, scope of the project, and diversity of backgrounds.  By
> making it clear that lack of “LGTM” from another team member equates
> with lack of consensus, we would avoid those misunderstandings.

I agree that firm conventions here would make things smoother. It's

common that someone offers an incomplete review or just forget the LGTM,

and the author is left to ask if it's OK to push or not or assume it is.

Toggle quote (15 lines)> A good reference on consensus-based decision making is
> <https://www.seedsforchange.org.uk/consensus>.
>
>> It's also worth noting that this consensus-based process has always
>> been implicit; for example, it is not defined/mentioned anywhere in
>> our documentation.  Perhaps it should?
>
> Those who’ve followed the project long enough, such as part of the
> current maintainer collective, are certainly aware of that; it’s also
> spelled out in
> <https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/>.
>
> That said, again in the spirit of improving legibility, writing it down
> would be much welcome.

Yes, I've heard 'consensus' for years, and I think I have a good enough
understanding of it, but I think there are subtleties many (including
myself) fail to appreciate that the above link explains well, so I think
there's value in mentioning it somewhere.  I'll send a patch for
everyone to review.

Toggle quote (39 lines)>>> In a way, that’s probably bound to happen as the group grows, and I
>>> think that’s why we must be explicit about what the process is and about
>>> whether one is expressing consent or dissent.
>>>
>>> With so many things happening in Guix (yay!), it’s also easy to overlook
>>> a change and realize when it’s too late.  By having a rule that at least
>>> one other person on the team must approve (consent to) a change, we
>>> reduce that risk.
>>>
>>> Being on a team, then, is a way to express interest on a topic and to be
>>> “in the loop”.
>>
>> That's already what teams can do!
>
> Yes and no.  With the amount of activity going on, it’s easy to overlook
> something.  The explicit synchronization point could mitigate that.
>
>> I'd argue giving them the extra powers that would be conferred to
>> teams in this is not needed/desirable.  Some committer not a regular
>> member of X team may still be confident enough to push a patch sitting
>> on the tracker, and I think they should be able to.
>
> Self-assessment becomes tricky that this scale; I might be confident and
> yet someone will point out a problem (that literally happened to me two
> days ago in <https://issues.guix.gnu.org/62062>).  That’s when review
> really helps.
>
> For “core” work, I insist that explicit approval (and thus peer review)
> is necessary.  I doubt anyone would seriously challenge that.
>
> Now, I agree, as I wrote before, that this may be overkill for “random
> packages”.
>
> Thus we need to find the right balance.
>
> What about team/scope-specific rules?  As in: “Changes covered by teams
> X, Y, and Z need to be explicitly approved by at least one other member
> of the team.”

To me, it seems challenging to partition the code correctly and avoid
overloading the core team with spurious changes, which would slow things
down more (as the core team would be a fraction of the committers
currently enabled to push such changes), but I agree in principle that
it makes sense.

Toggle quote (13 lines)>>> It is not about asserting power or building a hierarchy;
>>> it’s about formalizing existing relations and processes.
>>
>> OK; I think in practice it would amount to that though (building a
>> hierarchy which has some form power).
>
> I disagree: just because power relations are not spelled out doesn’t
> mean they don’t exist.  I don’t know where you’re talking from; one
> thing that to me shed light on these matters is “The Tyranny of
> Structurelessness” (I’m sure I mentioned it before, I certainly did
> during Q&A on this very topic at the Ten Years event; apologies if I
> sound like a broken record!).

As with anything there's probably a middle ground to reach, where
there's some structure, but not too much, that maximizes our collective
happiness.

-- 
Thanks,
Maxim

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 61894@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date