[bug#61894,RFC] Team approval for patches

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

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

> 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

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.

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

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

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

Hi,

On Wed, Mar 1, 2023 at 9:31 AM Christopher Baines <mail@cbaines.net> wrote:
>
> 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

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

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

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

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

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

Andreas Enge <andreas@enge.fr> writes:

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

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

Hi,

Maxim Cournoyer <maxim.cournoyer@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’.

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

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

Hello,

Am Tue, Mar 07, 2023 at 09:53:29AM +0800 schrieb 宋文武:
> 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

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

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

Hi,

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

> 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

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:

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

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

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

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.

> 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

Hi Efraim,

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

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

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

[...]

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

On 2023-03-08, Maxim Cournoyer 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.

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

Hi,

Vagrant Cascadian <vagrant@debian.org> writes:

[...]

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

Hi,

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

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

Subject: Thoughts on committers pushing simple changes from other committers?
1: <https://yhetil.org/guix/86k00avhpv.fsf@gmail.com>

Cheers,
simon

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/

Hi Simon et al.,

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

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

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

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

Hello Simon,

Am Thu, Mar 09, 2023 at 10:46:08AM +0100 schrieb Simon Tournier:
> 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

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?

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.

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

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:

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

or

        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>

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?

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

Am Fri, Mar 10, 2023 at 06:33:58PM +0100 schrieb Simon Tournier:
> 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).

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

Hi,

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

> 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

Hi Felix,

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

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

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

[...]

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

Hi Ludovic,

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

> 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

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

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

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

> 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 hope this clarifies my position!

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

Hi,

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

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

--8<---------------cut here---------------start------------->8---
+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).
--8<---------------cut here---------------end--------------->8---

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

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. :-)"

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

Hi Maxim,

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

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

--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---

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

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

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

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

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

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.

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.

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

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

Hi Ludovic,

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

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

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

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

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

Hello,

Ludovic Courtès <ludo@gnu.org> 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.

I think it’s fair to say that there was no consensus on this proposal,
so I’m withdrawing it and closing this issue.

Thanks to everyone who contributed to the discussion!

Ludo’.