unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ryan Prior <rprior@protonmail.com>
To: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Hero culture among Guix maintainers
Date: Sun, 02 May 2021 05:35:13 +0000	[thread overview]
Message-ID: <qnBbP_hwAcGOH4ihy73fV5AvvBDA0u-nyN2F059Q2e39Pv4CUVJ08_Ygsv2kKR5RNIA1c900LnaiieKRvEB4qFGPHeuRWxzcsoFv7IMq1sA=@protonmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4666 bytes --]

Hey Guix. There's a specific thing I'm motivated to address after the recent security incident with the "cosmetic" patches & all the fallout of that.

In one of the comments that lead off that thread, Mark asked "does anyone else find it worrisome that Raghav has commit access?" I speculate this comment may have predisposed some people to read subsequent comments from Mark as harsh or suspicious.

I distinctly remember reading that message and thinking "oh Mark is not amused." I'd write a message like that if I'd already tried privately to resolve a person's practices and they'd been resistant, causing me to give up on them and leaving me feeling little choice but assuming bad faith. I don't know what history the participants in that incident had with one another, I don't follow the list or know everybody well enough to have any knowledge or good guess.

One way or another, part of the subtext I got from that thread is that Mark, an established and respected senior contributor here, believes making an error like the one Léo and Raghav made is beneath the level of somebody who's entrusted with membership in the committer group. That reminds me of a common attitude I've seen in operations at a lot of companies, that ops are heroes who take their duties very seriously and feel an extreme responsibility to follow procedures and avoid using their power destructively.

That attitude is a liability at any organization, because we're all fallible and guaranteed to fault on occasions, but I think especially so in a high-trust inclusive atmosphere like what Guix has been building. I noticed that Léo joined, got really engaged with improving the software, and was quickly accepted as a committer, which I thought was really cool. I haven't applied for commit access myself yet, both because I have anxiety about acting out of line and thus want more time to learn the norms of the community, and also because I feel reasonably at ease with the tools and processes for non-committers to contribute. But I saw that and thought it was a great sign that a committed contributor like Léo was able to gain the group's trust so quickly. It's a strength and would be a shame to lose that.

But if everyone who's entrusted with commit access is also expected to live up to the heroic responsibilities of the classic ops/sysadmin role, then I think we're setting people up for failure. Ops at the best companies are guaranteed to make mistakes, and they have the cultural training to be Very Sorry about it and Learn Their Lesson and so on. But how do we expect every committer to a volunteer open source project to behave that way? Blaming a volunteer for a bad commit, calling them out on the mat to fess up and say they're sorry, is big "blame the intern" energy and it's ultimately not conducive to our security as an organization. I think that's still true even if you assume good faith and use only factual statements throughout.

It felt to me like Mark was expecting (demanding?) a certain cultural performance from Léo: acknowledgement of what was done wrong, contrition for his part in it, and a promise not to repeat it. This is typical in ops organizations, but it's not necessarily humane, and I don't think it's a reasonable expectation in a volunteer project. A reexamination of the hero culture among the Guix developers might be in order to avoid similar confrontations in the future.

What does it look like to step back from hero culture? One tool I've used working for paranoid security organizations is to require at least two signatures/sign-offs on any merge to a "protected" branch (like master or core-updates,) one of whom has to be part of a "security ops" subgroup who take on responsibility of this extra review. This pratice works on the simple acknowledgement that any given committer is fallible and two heads are better than one. It's impossible to know for sure, but I imagine this practice would have caught the mistake in Léo's commit to core-updates, and might have avoided a lot of anxiety. Some of Christopher Baines recent work on visualizing the impact of commits could also help aid this review task.

I'd also be interested to see a mechanism for marking commits in the "protected" branches as vulnerable, such that "pull" and "time-machine" can give a warning (or refuse to use those commits.) This might make occasional bad commits less catastrophic and thus reduce anxiety, allowing us to maintain a safer git tree without having to rewrite history or maintain heroically high standards of judgment about every commit.

Cheers, and an honest thank you for everybody's thoughtful messages this past week!
Ryan

[-- Attachment #2: Type: text/html, Size: 4951 bytes --]

             reply	other threads:[~2021-05-02  5:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-02  5:35 Ryan Prior [this message]
2021-05-02 11:56 ` Hero culture among Guix maintainers Jelle Licht
2021-05-08 10:43   ` Pierre Neidhardt

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='qnBbP_hwAcGOH4ihy73fV5AvvBDA0u-nyN2F059Q2e39Pv4CUVJ08_Ygsv2kKR5RNIA1c900LnaiieKRvEB4qFGPHeuRWxzcsoFv7IMq1sA=@protonmail.com' \
    --to=rprior@protonmail.com \
    --cc=guix-devel@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 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).