From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id YITbCPo4eWbhhgAAe85BDQ:P1 (envelope-from ) for ; Mon, 24 Jun 2024 09:14:34 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id YITbCPo4eWbhhgAAe85BDQ (envelope-from ) for ; Mon, 24 Jun 2024 11:14:34 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b="hp/XHtQw"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1719220474; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=lnSr8+6YQMEtp79f60EP26Fqz/TornlmGSnnINnTIb4=; b=O9ujjDwPxFoFpwtN9Gj7xbxgklL+Ul7IipwA05nNZYT52MPKwlJsSiKjOA8ForBuEYqxun Ne4rRzagHx4c0aMAAtxkdV3Q/IZ/ojmYVrlJqvGeffEdQmOzUaMTz9/nLgTy8HUKlPW2KJ dFy7jKIdjQoVJveQR6dhIyzRjPSQ0MSjcOjGMZDSI42K99XSAQN06gPzBZKOJoVKUvlqyK i4JB0Le5EWdp6cfWgtZDLtp5rlCtBpRTJLQMCqDltwWaTTKK1Evoan3FLPdENziQeX0PA2 g9urcV7dtxUcoeJaFVZ39XUlWU0POmkTstOAvSXa6+GI8ypgHb4o5cb7KRnfiQ== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1719220474; a=rsa-sha256; cv=pass; b=tYbYTFiqIHAnoUfArLHsN5oSC5CNjcgIZKSd/orS4Y0C3w00pXTvGxgt8Wd20olbR1wO6m mhEuzg+4xEayZ6r+XAYQWWZPSwvvA5zOzWnELvFpzq+SuYTGuuTvWGXPW1lHArp9s8EAyT Q3/YulWvDyoWaTIsR24wN2bjMrnkrsrSuYYZb5XWOzU+bnOm0W/A1BpYr9fiZJpdOYGxOn LL1dzPmC6KzIKf5lOv9DVk5DMrZ//B6CasXtHhyrb8fhZyPUSAmIRJ/2wFrVYrI/AkvNx1 maMef3tBsjB7m+E0spdaTjk5JFTcu5tfgtPmUJNgBS2n/GBq0B/s1koPyWrXvA== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b="hp/XHtQw"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; arc=pass ("zohomail.com:s=zohoarc:i=1") 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 EE4DD6DA3B for ; Mon, 24 Jun 2024 11:14:33 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLfm0-0007ke-8y; Mon, 24 Jun 2024 05:14:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sLfly-0007kU-KJ for guix-devel@gnu.org; Mon, 24 Jun 2024 05:14:02 -0400 Received: from sender4-of-o51.zoho.com ([136.143.188.51]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sLflw-0004Ek-Bg for guix-devel@gnu.org; Mon, 24 Jun 2024 05:14:02 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1719220422; cv=none; d=zohomail.com; s=zohoarc; b=d29tDZDH+4qJ8GZEJ6Jr4dEfvwCwaDH1ASfBzgYtUHIUiNc+AtkL64gi89fxQHRl5rA/wLWAkL9req+Vn0ONY6DlaikPScHBKBw9gZrmF4It/sdTy5WyxehX4BqeYYXYrisjM4Dxhiv/fsNbn2jz8JY3uj9W+JozJQkkpZ2Dsko= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1719220422; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=lnSr8+6YQMEtp79f60EP26Fqz/TornlmGSnnINnTIb4=; b=N9Xtwm5+mhBu8PohIw2uAw6bpUU84p/1GIneC6CTdMdthrKEPZP4dMsAQThhWXSNqdRSMaqT8HS0SrkhZRSyEXPqTaQAHyi1JJMigrVALearubZ+MCbXAqDK5kli0X22oNXGSkSGH94X20kBHRCYLTmrLr1awzzVS/JkgzcOVGs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1719220422; s=zoho; d=elephly.net; i=rekado@elephly.net; h=From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:Date:Date:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To; bh=lnSr8+6YQMEtp79f60EP26Fqz/TornlmGSnnINnTIb4=; b=hp/XHtQw2r23Y/zpPr7rhYg6T+IkE/WGVOv6E2NOqDjmDBRLavGqhqlGLH2X1Oj5 BJ8h65mEyxU4rDCYvcCOzMDxdJtk2vlhbAO2AY5qiJzIJEHoW88HIo6CN4plkB7cFHi A9Ht/65MaqQFJL+CFNYwFKxksG74pfeRGxKPUGDU= Received: by mx.zohomail.com with SMTPS id 1719220420095991.1548419108163; Mon, 24 Jun 2024 02:13:40 -0700 (PDT) From: Ricardo Wurmus To: MSavoritias Cc: Richard Sent , Andreas Enge , guix-devel@gnu.org Subject: Re: About SWH, let avoid the wrong discussion In-Reply-To: <20240624105556.7e92bc20@fannys.me> (MSavoritias's message of "Mon, 24 Jun 2024 10:55:56 +0300") References: <20240618113717.4a6bad2b@fannys.me> <87msnebsfd.fsf@gmail.com> <20240621121213.419da774@fannys.me> <20240621134439.5bc324b4@fannys.me> <87zfrdazzn.fsf@freakingpenguin.com> <20240622174242.7e1a18d5@fannys.me> <87cyo8zrd4.fsf@elephly.net> <20240624105556.7e92bc20@fannys.me> Date: Mon, 24 Jun 2024 11:13:35 +0200 Message-ID: <87r0cmya80.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.51; envelope-from=rekado@elephly.net; helo=sender4-of-o51.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: EE4DD6DA3B X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -10.26 X-Spam-Score: -10.26 X-TUID: gmEWOmONQyjF MSavoritias writes: >> > - Guix respects the consent of the person using guix lint and their expectations. (that lint actually lints) >> > - Respects their privacy >> > - Respects their autonomy. >> >> User autonomy is not curtailed by informing an aligned service's crawler >> that an update has occurred. You have a first class option to disable >> whatever checks you don't want to run. That's autonomy. > > It is in the sense that you haven't gotten the consent of the person > running the linter on something that happens outside the context of > "linting code". But look: here you switch from "autonomy" to "consent". You mentioned "autonomy" before, and that's what I responded to. Irrespective of whether I agree with your assertion on consent here, I think it is important not to conflate very different concepts when attempting to build consensus in a community discussion (lopsided as it may be). It's how we end up talking past each other as one word points to another, and we're led in circles. It's also why I think it was a valuable contribution to the discussion to draw a distinction between sending a URL and sending code. It may seem like nitpicking, but for me (in the role of the jaded observer whose detachment is either the result of having attained enlightenment or being uprooted by depression) it's a world of a difference: I'm okay with a notification containing a public URL being sent, but I'd be furious if my bytes were siphoned off. While I have my nit-picking hat on, allow me to but-ackshually: "Linting code" is not really what this is about, because we're dealing with *packages*, not arbitrary *code*. Within the context of Guix (which is not, for example, a general purpose programming language where the unit of interest is "code") I do think the assumption is a little too eagerly impressed by prior experience with programming tools. I'm not saying it's somebody's *fault* for having an assumption like this, I just think it's an unfortunate conflation of related but distinct concepts. > Because from the places I asked in xmpp and here it seems everybody > that is not reading the docs or knee deep in guix project, assumes it > just lints and is surprised it does more things. Yes, we've had similar problems in the past where documentation is not considered and individual assumptions (developed by other the use of other tools, because intuition is a lie) are used as the yard stick against which the behavior of tools is judged. Examples include "guix refresh", "guix package", "guix container", "guix archive", and even "guix repl". "Nuance" is an emergent property; no single word can be nuanced, so in my opinion a command name cannot possibly carry enough information to accurately represent the gamut of its behaviors. We can only hint at a general direction and use the term as an index into documentation. We have several layers of documentation; the first pointer would be into the output of "guix help". Perhaps changing the short description shown next to "guix lint" would reach those averse to documentation, to colour the pointer in ways that better hint at the concepts it points to in the manual? > Seeing how this thread has devolved I am wondering what the next steps > would be to address this. Seeing as diversity and a welcoming > environment wasn't kept. > Open to suggestions of course :) I think it is very difficult to feel welcome when people don't understand or disagree with you. I've been there myself, countless times before. The very attempt to express myself clearly is intensely uncomfortable; it's like walking on egg shells, but not because of a community failing, but because any error in representing my view point is going to make the waters more turbulent, confuse the issue, spawn requests for clarification, or sub-threads on issues that really don't matter to the originally intended point. And yet, all the properties of a pleasant community are exemplified in the process of untangling the knots of disagreement. I think it is dangerous to label the attempts to argue an opposing point of view and the attempts to define boundaries as "arguments in bad faith". This is a sure fire way of sabotaging one's own goals. We're all operating under very limited information about other people's points of view, their amount of information, their values and the amount of overlap with our own. For some of us, defining a topics boundaries is a precondition to understanding details within them. Passionate people often run the risk of steam rolling a budding discussion. [And this is my cue to disconnect from it again.] The sheer volume of messages can intimidate people and keep them from making their voice heard. (I, too, have been intimidated by this thread, even though there is no reasonable threat to my standing in the community if/when I make a fool of myself.) I read that in Sociocracy meetings, people speak up one after the other, in turns, and not again before everyone else has been heard. Here we don't even know who is in attendance, so that's not easily modeled. Also, email with its ever-branching sub-threads easily devolves into the average emacs-devel "discussion". Simon's proposed RFC process (which I support) aims to improve this by putting a consent-seeking process first. I think it would be a good alternative to whatever this is :) This topic would benefit from a declaration of statements (which members of the community can refute or agree with) and an actionable proposal. -- Ricardo PS: Unless specifically addressed, the above is not directed at any one person in particular. I'm only capable of seeing stories and themes, but the actors and their actions are all a big blur to me. Such is looking out from this here brain, smoothened by age and defeat.