From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id PllTK2+TjmC2ywAAgWs5BA (envelope-from ) for ; Sun, 02 May 2021 13:56:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id iHODJm+TjmBqEQAAB5/wlQ (envelope-from ) for ; Sun, 02 May 2021 11:56:31 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4C0F52D240 for ; Sun, 2 May 2021 13:56:31 +0200 (CEST) Received: from localhost ([::1]:46410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldAi6-0000uK-F5 for larch@yhetil.org; Sun, 02 May 2021 07:56:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldAhv-0000u9-Kq for guix-devel@gnu.org; Sun, 02 May 2021 07:56:19 -0400 Received: from mail1.fsfe.org ([2001:aa8:ffed:f5f3::151]:60706) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldAhs-0007Jy-LK for guix-devel@gnu.org; Sun, 02 May 2021 07:56:19 -0400 From: Jelle Licht To: Ryan Prior , "guix-devel@gnu.org" Subject: Re: Hero culture among Guix maintainers In-Reply-To: References: Date: Sun, 02 May 2021 13:56:11 +0200 Message-ID: <868s4x4aec.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2001:aa8:ffed:f5f3::151; envelope-from=jlicht@fsfe.org; helo=mail1.fsfe.org X-Spam_score_int: -68 X-Spam_score: -6.9 X-Spam_bar: ------ X-Spam_report: (-6.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619956591; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=7hiQ0ibs7aocfTD5enpDMK464XXQQTw46hy4hZ2C+i0=; b=BpF5ekyn7sxDF9J92UYxEqkernTQQ/3uGQczqUgbw92UjZ5/lRYm3MsbF8EaW0WYdEqqsA 4t5y7vQe34SRL5/3m8sSpNcGow6ur4c9DWXDEkmtWpM94ghbt9Tqaw37Fw28l4FzPRgFtc v4aZo8IVYVM6tzo1C+brGRgoBeKdxZCXEA99qzrxdHTavd6bnakXFUMK4dtRGzuh+JtX3o IkUjvvc32oGSxuJamca0XGU3BY5Vj4/XTKH0y9RcvEr3Zp1Ab1H0gYpLNg+0WXgCRP5rsE U+F6DQqpHphte8pXM064DWH7ll87q0szOmnnyL04av5x9tsl+92vA3Bt8uw4Kg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619956591; a=rsa-sha256; cv=none; b=WMbBvqnGxCgaoN80sV9KzNs4QWSoRsZMMKqW8YJW9S1jCAVhv53JPGrEKggBLVhLy6iryl VCbOWNVNezYEITxisB1FtAGn9Jec52Og9ciGv0SIUc9uMO29p44RzfOnWZ2e+hpjZ73G0l 5MjfTRG0fjLQtee3R4+lnpqSAL3Y+691Omfqi1LBRWGfWN5Uv/a3BqyoI3swhf5N1SROzd FTKEQu2p/XuzLIO8544DdwIeLEqlKoB9gdsmm/HhP8QGgQDfHuE/SYXKt3SYPzSvnkUWDx d/C9sZppNXmochuSAP2v39zugvxq9TvEQWnglcpOMZTWPIOR4cdXDg1qsngUPA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=fsfe.org (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -0.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=fsfe.org (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 4C0F52D240 X-Spam-Score: -0.86 X-Migadu-Scanner: scn0.migadu.com X-TUID: ltfXK7s1uz9Z Hello Ryan, tl;dr: (!=3D 'accountability 'blame), but accountability is essential to any social endeavour. Ryan Prior writes: > 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. Some proposals and ideas have been put forward on how to prevent situations such as the recent one from getting to the ugly point they did. I do understand the values of the proposed ideas, yet I think they are an orthogonal concern to what actually went on here, and that is vagueness on the nature of accountability (and trust, to a lesser extent). > 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=C3=A9o 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. If you can indulge me a bit and allow me to make a snide remark: I sincerely hope we hold folks to the standard of not using their power destructively, in the general case. What do you think trust is, essentially? To me, it means exactly what you describe as being a hero; being expected to be accountable for your actions and commitments.=20 That is not to say that anyone has the expectation you won't be making mistakes; you will, inevitably. But it is your own responsibility to either decline the accountability, or to live up to it. Is that scary? Yes, but so is driving a car the first time, or caring for a newborn, or operating heavy machinery etc etc. > 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=C3=A9o joined, got really engaged with improvi= ng > 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=C3=A9o was able to gain the group's trust so > quickly. It's a strength and would be a shame to lose that. What you describe as hero culture comes across as an uncharitable interpretation of accountability in general, IMHO. Things only get iffy if accountability is seen as a zero sum game; 'someone else's mistakes are my Golden Ticket to a promotion'. Guix does not seem to be such a project to me. > 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. Because of language barriers this might not be a clear distinction (at least in my mother tongue), but accountability in a functional organisation is not at all about blame. It is about being criticial, reflective and open minded on your role and how one can contribute to reach a desired outcome. Very often, that involves stating "I forked up" in case you made an honest mistake. From my point of view, folks are given the benefit of the doubt in most cases in the Guix community. > It felt to me like Mark was expecting (demanding?) a certain cultural > performance from L=C3=A9o: 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 you refer to as a cultural performance, might be just that, but it does serve a set of important functions; 1 (short) confirmation that there was no act of bad faith (e.g. "Oops, my mistake") 2 clarify continued dedication to the goals of the organisation/group 3 actionable steps to possibly prevent the mistake from happening again. Only then is it appropriate to start listing mitigating circumstances. There are situations where one is accountable, but could not have prevented a problem from occurring in the first place, but only after the previous three steps is the 'right' time to push one's side of the narrative. Without that, you are not perceived to be taking your accountability seriously. (Mind you, I do this wrong 90% of the time, I'm just describing the asymptotic 'perfect'). Technology-minded folks often want to skip steps 1 and 2, which leads to frustration and the breaking down of trust, at least in the short term, which is shame. One could ask, "why don't we just skip steps 1 and 2, and assume that those are implied?", but that is a recipe for disaster; Only the entire thing together shows that somebody is still committed to being held accountable. Leave out any of the steps, and misunderstandings can and will arise. A valid and praise-worthy way to resolve such a situation is to reconsider being accountable, and step down from a certain role/position. > 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=C3=A9o'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. L=C3=A9o (or you, or me, or anyone) will find new, more interesting ways to make mistakes. Note that I am not stating we should not prevent preventable mistakes! I am simply stating that your proposal would have simply delayed the issue at hand, not prevented it entire.=20 I'd rather (additionaly) work towards a more sustainable solution, which I think needs to be an agreement on what accountability (in the context of Guix) is (or should be!). > 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. My first practical contribution in this reply: this seems like a cool workflow enhancement to have, indeed! > Cheers, and an honest thank you for everybody's thoughtful messages this = past week! > Ryan Thank you for your very well formulated message! - Jelle