all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: Guix Devel <guix-devel@gnu.org>,
	 GNU Guix maintainers <guix-maintainers@gnu.org>
Subject: Re: On commit access, patch review, and remaining healthy
Date: Mon, 06 Jun 2022 23:43:36 +0200	[thread overview]
Message-ID: <87fskha2nr.fsf@gnu.org> (raw)
In-Reply-To: <877d5um1oe.fsf@systemreboot.net> (Arun Isaac's message of "Mon,  06 Jun 2022 17:41:45 +0530")

Hi Arun,

Arun Isaac <arunisaac@systemreboot.net> skribis:

> Tooling aside, at least for me, I think there is an important emotional
> and psychological aspect to patch review. Maybe others share it too. So,
> I'll speak up.

Thanks a lot for speaking up, your feedback is invaluable.

I did consider that the whole process could be intimidated; that even an
experienced contributor like you finds it intimidating is a red flag to
me.

> Sometimes, I don't review and commit patches because I feel like I am
> not qualified to review them, and am afraid of pushing a "bad
> commit". Guix has very high coding standards (which I very much
> appreciate, BTW), but that means that there is a high cost of failure
> and a pressure to live up to that high standard. This means that even if
> I'm 99% sure of a commit, I tend to leave it to others because of that
> nagging 1% doubt I have about some trivial aspect of the patch. The 1%
> doubt could even be about really trivial things like indentation or the
> name of a variable. In other words, perfectionism causes paralysis.

OK, understood.

I can think of two ways to reassure committers:

  1. By having clear reviewer check lists (you’d do that if you tick all
     the boxes, you’re fine);

  2. By improving automation—nothing new here: if there was a tick that
     says “applies without merge conflicts” and another one that read
     “builds fine”, anyone could lightheartedly hit the “merge” button.

#2 is going to take time I’m afraid, but at least #1 is actionable
(‘guix lint’ should help, too).

WDYT?  Are there other possibilities that come to mind?

> This excessive self-doubt is created by feeling like one doesn't
> "belong" in the elite community of Guix hackers. This problem may be
> alleviated somewhat by having more frequent (say, once in 3–4 months)
> meetups and encouraging participation by shy people like myself. Having
> human non-technical relationships with other members of the Guix
> community can also go a long way. The WhereIsEveryone meetups already
> help greatly. Perhaps Ricardo's idea of guix-mentors is another
> direction worth pursuing.

That’s a more subjective aspect, but a crucial one.  That perception of
an elite hacker community and the corresponding impostor syndrome are
problematic.  We long-time contributors should meditate that.

And yes, we should take advantage of the WhereIsEveryone meetups and
guix-mentors to get to know each other, to help each other, and to
demystify the whole thing.

> If this same thread had come up a year or two ago, I would most likely
> have remained silent. The only reason I feel alright talking today is
> because recently I have got to know more members of the community
> "face-to-face" (through online meetings), and feel more comfortable
> opening up. I generally prefer text-only communication like email, but
> sometimes, putting a human face on people and having a casual
> conversation about nothing in particular, goes a long long way.

Agreed.

Thank you for sharing how you feel about the process, it’s much
appreciated.

Ludo’.


  reply	other threads:[~2022-06-06 21:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 15:10 On commit access, patch review, and remaining healthy Ludovic Courtès
2022-06-02 20:22 ` Brian Cully via Development of GNU Guix and the GNU System distribution.
2022-06-03 19:37   ` Ludovic Courtès
2022-06-03 21:17     ` Ricardo Wurmus
2022-06-04 12:32     ` [bug#55794] doc: Add debbugs-gnu-guix command for Emacs Oleg Pykhalov
2022-06-07  7:08     ` On commit access, patch review, and remaining healthy Efraim Flashner
2022-06-07 15:11       ` Ludovic Courtès
2022-06-08 11:39         ` Efraim Flashner
2022-06-08 21:10           ` Ludovic Courtès
2022-06-20 12:53         ` Hartmut Goebel
2022-06-21 15:44           ` zimoun
2022-06-22  9:19             ` Munyoki Kilyungi
2022-06-02 20:32 ` Pier-Hugues Pellerin
2022-06-03 19:42   ` Ludovic Courtès
2022-06-02 21:35 ` Luis Felipe
2022-06-03  8:22   ` Feed on specific topic (public-inbox?) zimoun
2022-06-03 10:51     ` zimoun
2022-06-06 12:11 ` On commit access, patch review, and remaining healthy Arun Isaac
2022-06-06 21:43   ` Ludovic Courtès [this message]
2022-06-07  6:44     ` zimoun
2022-06-08  9:30       ` Giovanni Biscuolo
2022-06-14 12:24         ` zimoun
2022-06-15  7:01           ` Arun Isaac
2022-06-15  9:19             ` Ludovic Courtès
2022-06-19  6:55             ` Paul Jewell
2022-06-20 12:11               ` Arun Isaac
2022-06-15 15:11           ` Giovanni Biscuolo
2022-06-08 10:54     ` Giovanni Biscuolo
2022-06-09 19:55     ` Arun Isaac
2022-06-08  9:49   ` Giovanni Biscuolo
2022-06-09 19:50     ` Arun Isaac
2022-06-10 12:27       ` Giovanni Biscuolo
2022-06-10 15:03         ` Efraim Flashner
2022-06-10 16:10           ` Giovanni Biscuolo
2022-06-10 16:26           ` Giovanni Biscuolo
2022-06-10 15:03         ` Maxime Devos
2022-06-11  4:13         ` Thiago Jung Bauermann
2022-06-11  9:37           ` Ludovic Courtès
2022-06-14 11:54           ` zimoun
2022-06-14 15:54             ` Maxim Cournoyer
2022-06-15  6:46               ` Arun Isaac
2022-06-13 12:19         ` Arun Isaac
     [not found] <mailman.12124.1654864076.1231.guix-devel@gnu.org>
2022-06-12  8:18 ` Ricardo Wurmus
2022-06-12  9:42   ` Giovanni Biscuolo
2022-06-12 13:10     ` Maxime Devos
2022-06-13  9:34       ` Giovanni Biscuolo
2022-06-13 10:48         ` Maxime Devos
2022-06-13 14:21           ` Giovanni Biscuolo
2022-06-12  8:21 ` Ricardo Wurmus

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fskha2nr.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=arunisaac@systemreboot.net \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.