From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id OIJsJC5m/GTDoAAAauVa8A:P1 (envelope-from ) for ; Sat, 09 Sep 2023 14:33:50 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id OIJsJC5m/GTDoAAAauVa8A (envelope-from ) for ; Sat, 09 Sep 2023 14:33:50 +0200 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 393E266A22 for ; Sat, 9 Sep 2023 14:33:50 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=F3rWhYVX; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694262830; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=2VFfleAouwZKKdcJIX1OwDnsv1gioV16cMo2DL+DKsg=; b=fNqsCzyUzaZxWh1b+zMeem2QT7NULv84QYM4qrp7nv5Sy2hArI2vZSnij6CwlQxwfQRbpj P0ixSOS5ctVrR8jJlzpnUo4RYn1moPkPTfkrJIcUNP305312UfcshAHk31Mh/uzmMgWjYl Nn7FTnpFKzhej23E1sITUK0cQLGTQGbT7dlhe5vtyOFsYkns1LRCGAvleijfHefwdPmr9b vxTzcJtijeLWw8ypZ7SE7lmkCxYddS7it37Fw61jGVbN0UGcB+ZsJxRO4aYE7VpByondxp LsukWzIrT4kdb+WDf5n2LIgNiKF21rrZ88AKqACvliiONKyM7915d7t9TMDeww== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=F3rWhYVX; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694262830; a=rsa-sha256; cv=none; b=rgFWnWDkepfOP57xBP3omTdxFCCpSiH64Nm0aYkB05l+c1cRcvsKg2uZ9Dfg+cjBOshkyu xcqAbGRZnrxuyCjB+xj1uWX1irFtvoD/xfAni9B5Le2snlxbNsFWF9G53c74OW/o/0cY1Z qepwaOvSVZTGQ4i+R5h1OR8gUiTwXZFxavOUR91QnvQZVNygPbVsR4BHNOiwmmmo2mMfsp agp9u/Q1KjQvbhN4c3WQ6Ricx4ZiyheIi4xxe4BLjZZYzIjup9g+xtRbbgPTSOJGsjdWzw ewjfoVnvn8WAnVdNm+bCQIvG4I+Os2m/YrqgJRduGI4qDS/xZgZm5+Aky3QnWg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qex9G-0002te-FA; Sat, 09 Sep 2023 08:33:14 -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 1qex9B-0002sc-Rz for guix-devel@gnu.org; Sat, 09 Sep 2023 08:33:10 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qex96-0004di-0f for guix-devel@gnu.org; Sat, 09 Sep 2023 08:33:09 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-401e6ce2d9fso8306265e9.1 for ; Sat, 09 Sep 2023 05:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694262782; x=1694867582; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=2VFfleAouwZKKdcJIX1OwDnsv1gioV16cMo2DL+DKsg=; b=F3rWhYVXKWB0mvCYmA8PacgBqerwNyYl6qQKbfipO7Z2QGRGwKluheg8Tt2BRsoCAG 8MBDt0haAeCabpAun7wGjuUbTYeEeFl5huJNnskKvErHnlykhFrwNSusP/yzhaXNogyn SVaysJTfh7UVnrWlGfFRu6B4kfRUT7PTAuakzwNDNVWpmDueRxy2QlyxdBd3IKCXU5nk gdZYrCkY4J+4k6daNYzTpBTIXe0VYNrh2IsmDE6uSaR6LdXRKK5+YiJ721KcQsF8aeLw qI9vlsqYUvUtTO6LR+mbWD9e69Ow9J/mU71B4HERM6UmEIfIo/dATLo5phc58qDKbduY KKgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694262782; x=1694867582; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2VFfleAouwZKKdcJIX1OwDnsv1gioV16cMo2DL+DKsg=; b=hhejqRjByXCALc7sff3DjpTySipFaMYsrFmp89Q2J5UloFq2uxS0l1YBCocke79cq6 fMRI7Z9zov1jbScFcHD9NPe+lqxc3R2oVF7nJBIfff9VtEb9qfDDMuHlnZrsnbonSJqM wT1xaBMm46Nj3NNE6nUDLrMav/rxJFbD02rm8CoUhAW+WejA0x6NR7pDsRSbtzSANsv/ ATw+s0xgdYStDQVtpEODwgNlaINOIQApKe2Un1Ze7KufHXyvRbvF/cLFpwrEKxuXa9fr AFipXuSbpXT8nJbHjb1xXJm9v4hacvHRUyz84hs1svV9sJxbWPYUoLzdvv118K0WR48G hInA== X-Gm-Message-State: AOJu0YwotgmA1wgM1cdcMSI1TIw+CenIpwaF8Tr6gtpDg+9jU+lzKdWm fVgPS/m3/cRhxafxvhIhNm+pvCkTOQc= X-Google-Smtp-Source: AGHT+IHiGB4ZLmnHeU5Go6bcq7AmTqc5fTgQrQsU37Vu3a1t6qxGP4D/Db3mjAn18Dw9mvs37WHwuQ== X-Received: by 2002:adf:e7c7:0:b0:31a:ea18:c516 with SMTP id e7-20020adfe7c7000000b0031aea18c516mr3897772wrn.3.1694262782276; Sat, 09 Sep 2023 05:33:02 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id b8-20020adff248000000b0031c5b380291sm4715454wrp.110.2023.09.09.05.33.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Sep 2023 05:33:01 -0700 (PDT) From: Simon Tournier To: Katherine Cox-Buday , Maxim Cournoyer , Saku Laesvuori Cc: Attila Lendvai , Liliana Marie Prikler , Andreas Enge , "Felix Lechner via Development of GNU Guix and the GNU Systemtdistribution." Subject: Re: How can we decrease the cognitive overhead for contributors? In-Reply-To: <37edb289-d49e-0d74-05f2-4cc93c6129aa@gmail.com> References: <20230827135726.y33t55w4cvq6zsvb@X-kone> <874jkift8v.fsf@gmail.com> <867cp4sj7k.fsf@gmail.com> <38242808-2f06-4674-3842-aea1a5378d05@gmail.com> <86v8cop6sy.fsf@gmail.com> <8634zrpt40.fsf@gmail.com> <37edb289-d49e-0d74-05f2-4cc93c6129aa@gmail.com> Date: Sat, 09 Sep 2023 14:32:50 +0200 Message-ID: <867cozr0gd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32a.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: 393E266A22 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -1.93 X-Spam-Score: -1.93 X-TUID: JsXpwi/zXN0Z Hi Katherine, On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday wrote: =20 >> Maybe it's time to take a step back and instead of asking =E2= =80=9CHow can we >> decrease the cognitive overhead for contributors?=E2=80=9D, we = should perhaps >> ask =E2=80=9CFor which contributors do we want to/can we decrea= se the cognitive >> overhead?=E2=80=9D > > That's interesting, because I view this as the antithesis of what Rich=20 > was trying to convey. > > That quote is at the end of a dismissive ad hominem response which has=20 > grossly misinterpreted this discussion, even attributes it to malice,=20 > seems to draw the conclusion that contributing to Guix should be left to= =20 > those for whom the current situation is fine, and even intimates that=20 > those who would like to improve the situation are incompetent. About the dismissive ad hominem response, sorry. I should have clearly mentioned that I was fully rejecting the rest but only keeping the argument I was quoting. > Here's the quote from Rich's talk: > > The fact that we throw these things around sort of casually=20 > saying, "Oh I > like to use that technology because it's simple. And when I say=20 > simple I > mean easy. *And when I'm saying easy, I mean, because I already k= now > something that looks very much like that*" is how this whole thing > degrades, and we can never have objective discussion about the=20 > qualities > that matter to us in our software. > > Rich is saying that there are intrinsic properties to approaches that=20 > make them simple, but possibly not easy, and that we shouldn't rest our=20 > arguments on claiming something is "easy", because that term is=20 > relative, and often related to familiarity. Familiarity is a hard bias=20 > to overcome. Yeah. I think I had already gotten it. ;-) For someone who already plays guitar, then ukulele is =E2=80=9Ceasy=E2=80= =9D. For someone who does not know any instrument or nothing about music, ukulele is =E2=80=9Chard=E2=80=9D. Although, the complexity of the ukulele is the = same in both cases. =C2=AB For which contributors do we want to/can we decrease the cognitive overhead? =C2=BB, so I read it as: do we discuss about someone who is alrea= dy playing guitar or someone who is knowing nothing about music. We already have the answer: we are speaking about someone who already plays guitar (a skilled programmer). As you said elsewhere in the thread, we are all different, we all have different backgrounds, etc. and the idea behind =E2=80=9Ceasy is relative=E2=80=9D implies that we= have to bound for whom it needs to be easy. =E2=80=9CHow can we decrease the cognitive overhead for contributors?=E2=80= =9D Here, contributor is not explicitly defined. In all the thread, the term =E2=80=99contributor=E2=80=99 is interpreted very differently. Well, I rep= eat my very first message: Well, from my point of view, we are using here the term =E2=80=9Ccontribution=E2=80=9D as it was one homogeneous thing. =20=20=20=20=20=20=20=20 [...] =20=20=20=20=20=20=20=20 For example, a two-line patch trivially updating one package is not the same contribution as several-to-many two-line patches more some package additions for updating all the R ecosystem. And that=E2=80=99s not the same as rewriting the Python build syste= m or as packaging the last version TensorFlow. The cognitive overhead for these 3 contributions is not the same. Therefore, the way to reduce the friction will not be the same, IMHO. A task is not =E2=80=9Ceasy=E2=80=9C by itself. It depends on 1. the compl= exity of the task and 2. on the person who does it. We are saying the same thing, no? Now, this discussion has identified various frictions that are useless and bring no value for the project. It is clear that we need to improve by smoothing or even maybe removing some of them. Somehow, now we have to discuss about specific task, task by task, and propose how to improve. Survey is one next action for collecting data. The other action for more automation is not clear yet. We need to open discussions about QA, scripts, etc. For what my opinion is worth. > Read charitably, this quote suggests that there is a singular, best, way= =20 > to do things, and that if it doesn't work for some, the problem is not=20 > the process, but that "those people" are incompetent. Saying it plainly and stretching a bit, yes =E2=80=9Ceasy is relative=E2=80= =9D means some people do not have the background to complete some process. Reading the word =E2=80=9Cincompetent=E2=80=9D as =E2=80=9Cnot possessing t= he necessary ability, skill, etc to do or carry out a task; incapable=E2=80=9D I am incompetent for playing guitar for example. And playing music is really not easy for me. And so? :-) It is related to the question: for whom it has to be easy. A good example is the switch to some web interface for the translation. Some translators does not have programming skills, so they are incompetent for programming, and it was not easy for them to configure the tools for contributing to translation. The improvement had been the removal of the friction by switching to some web interface. Now, the process is probably not easy for people like me that are not used to web interface, although interacting with web interface is a simpler task than configuring some tools for editing translation files. Somehow, the new web interface makes me =E2=80=9Cincompetent=E2=80=9D for translating. It i= s about finding the right balance. Hum, we are far from the initial discussion. ;-) Again, I think we are expressing the same thing and we are on the same wavelength, I guess. :-) > This is classic gatekeeping. Sorry, I do not see any gatekeeping. Because all seems open and many people are doing their best for helping. Maybe that does not work, maybe that=E2=80=99s not enough, yeah maybe but I do not see =E2=80=9Cthe p= ractice of controlling access to information, advanced levels of study, elite sections of society, etc=E2=80=9C. Well, are you French? ;-) Because I fee= l we are discussing unrelated points emerging although we are agree on the core and we just detail tiny variations of the same thing. :-) >>> - Differentiating the types of complexity (importantly defining >>> incidental complexity): https://youtu.be/SxdOUGdseq4?t=3D1173 >>=20 >> It appears to me that it is also what I have tried to say in my very >> first message [2]. :-) >>=20 >> Well, from my point of view, we are using here the term =E2=80= =9Ccontribution=E2=80=9D >> as it was one homogeneous thing. Instead, I think the term ref= ers to a >> range with a gradual complexity. And the improvements or tools= maybe >> also need to be gradual depending on this range. > > This is crucial, so please forgive me if I belabor this point. > > You are correct that there are a range of ways to contribute, and some=20 > of them are intrinsically more difficult. But irrespective of that range= =20 > of difficulty, *improving the accessibility and experience helps everyone= *. Are we on a wrong road? Because we speak about the same thing, I guess: a skilled programmer (you!) who wants to contribute to some packages and does not find it =E2=80=9Ceasy=E2=80=9D by pointing several apparent fricti= ons. So it means we have a problem! Period. :-) The question is how to improve? Now, after discussing it =E2=80=93 thank y= ou for opening this can of worms, it was necessary and this discussion is very helpful! =E2=80=93 we have some items to act on, no? Just to point, the root of the discussion about the commit message format is about complexity, not about easiness. Is the current format too complex than no one finds it easy? The various steps for checking and submitting patches are simple but they are not easy. Therefore, we must remove that because making hard as not value. About the commit message format, we could make it simpler, which would lead to probably have something easier, but would we keep the value we have with the current complexity? > On the contrary, throughout this thread, I've thought that you=20 > understood the larger picture. I'm just responding to points where I=20 > thought I could contribute something, or where the points I've made have= =20 > been challenged or questions have been asked. Thank you very much for all the efforts and time you are putting in this topic. They are worth and very fruitful. I totally agree with your words: If Guix is for everyone, then we should do our best to ensure everyone can contribute with the things they're skilled at. And my point of view is that is a very big task so we need to start somewhere and incrementally improve in order to reach this goal. Cheers, simon