From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cBnsJQpt92QArgAAG6o9tA:P1 (envelope-from ) for ; Tue, 05 Sep 2023 20:01:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cBnsJQpt92QArgAAG6o9tA (envelope-from ) for ; Tue, 05 Sep 2023 20:01:46 +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 528E255D5E for ; Tue, 5 Sep 2023 20:01:46 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=WgtTUqPA; 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=1693936906; 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=mmisT40x6yv00T0NvIJr+eFWLyxO4zciYAd6SR55JyQ=; b=rIzubrt4EI3iP1LkbOOrvUrEwZRsrBJQCUjFRz8e3MRqwvYISzGTlaH4isWMLyxmZmUw55 XYnoJa3mT/Tp31XFWa9CzC6Fbgcpgx9b9qs0dJ8FSwj55I3FLLqdVs+sdTpxWMd09K0Y0q S7BRGGB0kRjcRrPC13E30zYBGmp89V2MlCVR5AbP4WtO5LoAgsAvjLcoDoikLB4SwhsgpW xoqVgFyi6fUO0hrO0VnDSyNtq6Sqhgw1XxD45fTxvEb+mh+CkqFvTutP2i/BGvROe7ouvC 5fszgGc+wqtG/nbG03B3Wici/rCLPE7ilBJy4tDdOHcVRIFUH8l5L/uo/3Q4+Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693936906; a=rsa-sha256; cv=none; b=Tw5vrqF5ILvWG6jODT7zPZ6Sj0FJZsYBZFSpK5geYolNNfgG5VRqtW7+QPJxCa7gAn54qt fjfXMQCgaTvJyuie9i9t8pV5778wNTA0ouF7HIvMH2npFZnU/4UBwjvQd+ArMe9DKRG2Ir qOGak8pHsLPiPFVF7rIxIEYLvYIDDN09p5ueXbH3rpZ+XuXk4RCjVo8fl2/De+bQBObAvc 3JdnD3+oWsNHDWWAFizsyzKyOfmSXOlya00o/W9YR3m2C2aI0cZJxUYgvYgwouWSDGBo37 goiVmsXzradis4DKqXpIZkQraKOGeT0ubzO7c4LjJdoSOIGYO+1Q0WgQVwiHPA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=WgtTUqPA; 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 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdaMC-0001cM-PE; Tue, 05 Sep 2023 14:00:56 -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 1qdaMB-0001c1-1k for guix-devel@gnu.org; Tue, 05 Sep 2023 14:00:56 -0400 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdaM7-0000Xw-Gm for guix-devel@gnu.org; Tue, 05 Sep 2023 14:00:54 -0400 Received: by mail-io1-xd36.google.com with SMTP id ca18e2360f4ac-792707f78b5so121481239f.1 for ; Tue, 05 Sep 2023 11:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693936850; x=1694541650; darn=gnu.org; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mmisT40x6yv00T0NvIJr+eFWLyxO4zciYAd6SR55JyQ=; b=WgtTUqPAO3VPfuAPLZ1n0dTRa9D5O9ttglQesQfSBYzMT0g+y9UExVQVzYfM6STTJ8 nALdmqwkXqAC+1CLg5DIM4DPlYmHVxqzVR/WJUiEx3cw3z/7+3Bhax1bW9KL72FeNnis xQ8eRr+JqCQ8CY3QJW1PsSsV9HzGYMX1mRA0zrCS73la7aYJIKrRZQ/SKHaYvrZ0mKgC HXdGNp8sFCKm5aiBRf7k5on22g9FqMsvmZTA4jEXhD0dm5em+azoiN7Qtiln3yoqIQrA y3rJUNBoww2D+TUL6kFUTtpaiLMGCEUUSZGF9y02A6FAPz5Vts4sj8jYVh74q9JaHeu5 pogQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693936850; x=1694541650; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mmisT40x6yv00T0NvIJr+eFWLyxO4zciYAd6SR55JyQ=; b=csEomJBTaSp3jQlllcnHMDeuRmymXCBfPCNwIGJSIhi4S3gkJLwMbXJOSh/9oLLh21 QJPvCFf/mSXzhI1P1yVul3BEWnRLlrcv9Ggr3Qb8zzLQDiC0XAMOw/E2uYmw+YjQC8vc og5qMaCl/FmPaQDU8Myv5J5UWWE5eTbQJ82h6fE8LbrDwkn8qz4GGEinfh5s14CZaftb XPbIqIZYweqKu2hXpBvnExSPP9mGB17UBOthOcPhhJ+SZgMf3i9zTLNBg3hfe8DFZbWB whF+mlWzamwwy1VZQM6kLiR2HvXE7870Qulgcbm9msAjQY2XURRy08/ffr4Mlj/SVsL0 ef/w== X-Gm-Message-State: AOJu0Yx/BzGpKpgNTCMx22zBLejTOMB/kZRQEtHUlTFWRzf3StiDHeJy xW1gikuMpNB7v85X+LHpMhk= X-Google-Smtp-Source: AGHT+IFtHO6OwIKGJGLBrLptFR6IQEmAmOu0KiG7ZXiKpxwrRjeyrO1pYiGw2E4U1aXDaIpoSY7lCw== X-Received: by 2002:a92:dc0f:0:b0:345:af82:dc3a with SMTP id t15-20020a92dc0f000000b00345af82dc3amr15362516iln.14.1693936850079; Tue, 05 Sep 2023 11:00:50 -0700 (PDT) Received: from [10.0.2.153] (c-174-51-218-141.hsd1.co.comcast.net. [174.51.218.141]) by smtp.gmail.com with ESMTPSA id z7-20020a92cec7000000b00348ebe3ba0esm4336567ilq.26.2023.09.05.11.00.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 11:00:49 -0700 (PDT) Message-ID: <3214a171-dcd5-335c-6339-df5dd0f5bfc6@gmail.com> Date: Tue, 5 Sep 2023 12:00:47 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: How can we decrease the cognitive overhead for contributors? Content-Language: en-US To: Simon Tournier , guix-devel Cc: Vagrant Cascadian Newsgroups: gmane.comp.gnu.guix.devel References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> <861qfcvhw2.fsf@gmail.com> From: Katherine Cox-Buday In-Reply-To: <861qfcvhw2.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::d36; envelope-from=cox.katherine.e@gmail.com; helo=mail-io1-xd36.google.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 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, NICE_REPLY_A=-1.473, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx2.migadu.com X-Spam-Score: -8.59 X-Migadu-Queue-Id: 528E255D5E X-Migadu-Spam-Score: -8.59 X-TUID: pw83FiG4RcgX On 9/5/23 8:01 AM, Simon Tournier wrote: > Hi Katherine, > > Thank you for your extensive analysis. I concur. > > On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: > >> 3. We should reify a way for Guix, the project, to measure, and track >> progress, >>    against long-term goals. Particularly when they're social and not >> strictly >>    technical. > > That is the most difficult part, IMHO. Well, what are the long-term > goals? :-) > > I am almost sure we will get various answers depending on people. Let > say the long-term goals of the Guix project are: Liberating, Dependable > and Hackable. Then how do you give concrete quantities that we can > measure or track? I think starting at the top and trying to derive concrete quantities from values is a healthy exercise. I agree that it's difficult, but without doing that it's easy to be left in an echo-chamber where your project isn't actually accomplishing any of the things you'd like it to. However, my point (3) above is a little different and easier. Here we have a lower-level goal that is a closer to a concrete quantity: "The overhead of contributing to Guix should be low." There are various ways to reduce this further, but they are tightly coupled to the method of measurement. In other words, what you measure will be what you manage, so choose what you measure carefully. > And it is always difficult, if not impossible, to measure or track some > goals that are not technical but social. For example, how do you > measure being welcoming or being a safe place for all? I think the easiest way to start, and something that's actually pretty effective, is to start doing annual surveys, e.g.: - https://discourse.nixos.org/t/2022-nix-survey-results/18983 - https://survey.stackoverflow.co/2023/ - https://tip.golang.org/blog/survey2023-q1-results This thread turned out to be an informal survey, and I think it's easy to see that some people are happy with how things are, and some people would like to see change. With a survey you can quantify these opinions and say things like "X% of people would like the current contribution process to remain the same. Y% of those are committers." This can help reveal larger patterns, and over time, trends. > Do not take me wrong, I strongly think we must think again and again on > that point for improving. It’s just easier to tackle technical bug. :-) It's definitely not as easy as tackling a technical bug. I think as engineers we often have a difficult time admitting to ourselves that efficacy is much more than the perfect algorithm or the mechanical shuffling of things around. Do we want Guix to be a fun technical exercise? Or do we want it to fulfill its stated goals? Why not both! :) > Here I see two annoyances: > > 1. The number of subcommands and steps. > 2. Each subcommand has a list of options to digest. > > Well, CI is helpful here, for sure. However, it would be helpful to > have a script similar as etc/teams.scm or etc/committer.scm that would > help to run all these steps. Yes, and commonly whatever you would use for CI is the same thing you would run locally. This is intentional so that you can have some confidence that CI will pass. > It does not mean that all these steps need to be run before each > submission. However having a tool would help irregular contributors or > newcomers; it would decrease the cognitive overhead i.e., that overhead > would be pushed to some script and it would reinforce confidence. And then although we've reduced the cognitive overhead globally, we've increased it locally by introducing another conditional: "do I need to run the CI script? how do i know?" The script could probably decide this too. > Now someone™ needs to implement this script. ;-) Collectively, I don't think we've arrived at a consensus on 1. A list of the issues 2. How we'll measure that they're issues 3. How we'll measure improvement against the issues 4. How we'll address the issues So often in my long career I've worked with organizations/people that really want to skip to (5): implement something. Implement a vertically-integrated solution to gather feedback against reality: yes. Jump straight to the "final solution" with all the details managed: no. > To be fair, here you forget one important blocker: having an account to > the forge website. > > I do not speak about freedom issues. Just about the fact to open an > account to the forge website. For example, let consider this project: > > https://framagit.org/upt/upt > > And if I want to contribute with a Merge-Request, I need to open an > account to the Gitlab instance of FramaGit and push my code to this > instance, even if I already have my fork living on my own Git > repository and I have no plan to use this FramaGit forge. You're correct, you usually have to have an account on some forge website. Think of how various solutions scale: do you have to create an account on a forge website every time you make a commit? And the point of that section was trying to think about what the forge website's button does for the committer, and less about stating that its superior or that we should definitely adopt it. A lot of this thread has turned into a debate on specific tools instead of thinking about what the underlying problems are, and the various ways to address those. Tooling is an implementation detail. > Please note that it is not truly about the complexity of the steps but > about how many steps one is able to complete between two interruptions. My intention was for it to be about the complexity/overhead in aggregate. Collected, I think all the steps, and their flags, and the decisions that go into which steps, and which flags, and what values, should be considered as "complex". > Well, it is a well-known issue about task switching [1]. :-) > > 1: https://en.wikipedia.org/wiki/Task_switching_(psychology) That it is! And what's the first line in that article? "Task switching, or set-shifting, is an executive function[...]". So are we unintentionally filtering out contributions from people with compromised executive functioning?