From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: "Simon Tournier" <zimon.toutoune@gmail.com>,
"Andreas Enge" <andreas@enge.fr>, 宋文武 <iyzsong@envs.net>,
"Christopher Baines" <mail@cbaines.net>,
guix-devel@gnu.org, 61894@debbugs.gnu.org,
guix-maintainers@gnu.org
Subject: Re: bug#61894: [PATCH RFC] Team approval for patches
Date: Fri, 10 Mar 2023 18:22:07 +0100 [thread overview]
Message-ID: <87bkl0frnk.fsf@gnu.org> (raw)
In-Reply-To: <874jqtte7c.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 09 Mar 2023 23:36:39 -0500")
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’.
next prev parent reply other threads:[~2023-03-10 17:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 16:13 [bug#61894] [PATCH RFC] Team approval for patches Ludovic Courtès
2023-03-01 17:15 ` Christopher Baines
2023-03-01 17:59 ` Björn Höfling
2023-03-01 18:17 ` Christopher Baines
2023-03-01 19:21 ` Felix Lechner via Guix-patches via
2023-03-01 22:45 ` Ludovic Courtès
2023-03-02 11:04 ` Andreas Enge
2023-03-02 13:57 ` bug#61894: " bokr
2023-03-03 1:08 ` 宋文武
2023-03-07 1:53 ` [bug#61894] " 宋文武 via Guix-patches via
2023-03-07 10:36 ` bug#61894: " Andreas Enge
2023-03-07 12:22 ` Simon Tournier
2023-03-07 18:29 ` [bug#61894] " Maxim Cournoyer
2023-03-07 22:40 ` Leo Famulari
2023-03-08 18:58 ` bug#61894: " Maxim Cournoyer
2023-03-09 8:48 ` [bug#61894] " Simon Tournier
2023-03-08 9:12 ` bug#61894: " Efraim Flashner
2023-03-08 17:05 ` Maxim Cournoyer
2023-03-08 23:38 ` Vagrant Cascadian
2023-03-09 5:12 ` Maxim Cournoyer
2023-03-09 9:46 ` Simon Tournier
2023-03-10 4:36 ` Maxim Cournoyer
2023-03-10 17:22 ` Ludovic Courtès [this message]
2023-03-10 18:22 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-03-12 2:33 ` Maxim Cournoyer
2023-03-12 11:14 ` Simon Tournier
2023-03-12 3:26 ` Maxim Cournoyer
2023-03-12 11:52 ` Andreas Enge
2023-03-13 0:08 ` Maxim Cournoyer
2023-03-12 12:25 ` Simon Tournier
2023-03-15 16:08 ` Ludovic Courtès
2023-03-17 15:46 ` [bug#61894] " Maxim Cournoyer
2023-03-10 14:19 ` bug#61894: " Andreas Enge
2023-03-10 17:33 ` Simon Tournier
2023-03-10 23:19 ` Andreas Enge
2023-03-11 13:20 ` Simon Tournier
2023-03-07 15:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-03-06 15:48 ` [bug#61894] " Maxim Cournoyer
2023-03-06 21:42 ` Ludovic Courtès
2023-06-02 13:50 ` bug#61894: " Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2023-03-13 16:30 Peter Polidoro
2023-03-14 15:58 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkl0frnk.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=61894@debbugs.gnu.org \
--cc=andreas@enge.fr \
--cc=guix-devel@gnu.org \
--cc=guix-maintainers@gnu.org \
--cc=iyzsong@envs.net \
--cc=mail@cbaines.net \
--cc=maxim.cournoyer@gmail.com \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).