From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 EMdtGki6AWXregEAG6o9tA:P1 (envelope-from ) for ; Wed, 13 Sep 2023 15:34:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id EMdtGki6AWXregEAG6o9tA (envelope-from ) for ; Wed, 13 Sep 2023 15:34:00 +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 017375D3C5 for ; Wed, 13 Sep 2023 15:33:59 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b=D5iCV2Xr; 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=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694612040; 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=WKDXA8V5h1x1O0vmhjh+VGYB9ehCIwBydeiBqfdnKu8=; b=GW+mfs4tnHHlXx4RX9lPaC3tTD48GwnGL03FqHN0noLEgryJhYkpn22aFu9I872X2VLJHp JNLBbkAhWWRqzbUSnf76vPxR/wPituT6XzrX2P60WzsY+LFy3NDmqmYJuwyI1YLvD4Bjq7 CFdm9eISKmnVH6xz3FBHrcZEKzX/8XfrAfRvOIJUs1B758o63OMY4fZdtvdKGPwqe6KqL7 cH9dc/806AXGLrrrrheDd33a9NW+y/hl0oSbNf9CA9XJly8DmKkWjIr1Hsegi6ei6NjtW+ UiLW5xcXMKNyrjGqRX3jA5aaUtsB4XKRvuj3v14sASexxLnJ1Y6u3+9odBd0ow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b=D5iCV2Xr; 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=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694612040; a=rsa-sha256; cv=none; b=csRpo+Ji1AzJNbEw0fHwlxg/WomgcUZilOCyUpsA+737di+Lx19uH+nCBL0YyPT1oHnRfv R3liGleGeggsfP+g4QDmkGaBieqMWeQcXfJmUvNOQdeREn37tbw5pzRVW0iMLxf5rvIMHb /KLhhh0AZDf6fRmlb4dffaw8c52EkrZPmnjeHhSeBB7IELR56k6rb1XYFCc7rc2THWHoaW P1LE80qcycuih8C4BTLp3y7zUdZQLFTEB2FwoW+FRTe5Wa9hlP0s4KXsdI5/HSpCq/J+Xl hLSBDf/Ff3FcQURj1YjCzBOo1n6C/e8cRT7Lh14FQbHWCU3csp+XA/x6gazOsg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgPzg-0007rg-Bc; Wed, 13 Sep 2023 09:33:25 -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 1qgPzP-0007mv-DX for guix-devel@gnu.org; Wed, 13 Sep 2023 09:33:08 -0400 Received: from mail.webarch.email ([81.95.52.48]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgPzK-000176-4W for guix-devel@gnu.org; Wed, 13 Sep 2023 09:33:07 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9D8FF1A83F28; Wed, 13 Sep 2023 14:32:53 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msavoritias.me; s=20210930; t=1694611978; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=WKDXA8V5h1x1O0vmhjh+VGYB9ehCIwBydeiBqfdnKu8=; b=D5iCV2XrXvRo6ldxbIhCcn3qj7e6B0k6unlZjix1r7P9H32aiwbOhWUZ3pEihOgCJdO5t5 +1JscqKzKbEhneVX/gnWCIVPTxdHeQ66oCkaVLlnNOgvRx3jigWyRJ9P8m7KRoZioObGxY WQXba71YzbH5aOhL7rSwbZDuM4nj1E6/ponIXW3vzfIQzSFMLcJBOiaZPCqR5XCq8yELz0 gsBij0xOf4NEaD1qBWJnZWImPZAZhAs8vtW32fvYbGdI6Gvd8jeVQGm0eMbh4XmHXEkooG u7I8iBXJOehZerpU6sDg5ddolKZUO8nE8SzeEFzzMHJIjFWVSsMaFY4jt6wHqg== References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> <877cp8965f.fsf@xelera.eu> User-agent: mu4e 1.10.5; emacs 28.2 From: MSavoritias To: Giovanni Biscuolo Cc: Katherine Cox-Buday , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? Date: Wed, 13 Sep 2023 16:24:21 +0300 In-reply-to: <877cp8965f.fsf@xelera.eu> Message-ID: <87o7i6ryf8.fsf@fannys.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Received-SPF: pass client-ip=81.95.52.48; envelope-from=email@msavoritias.me; helo=mail.webarch.email X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -0.31 X-Spam-Score: -0.31 X-Migadu-Queue-Id: 017375D3C5 X-TUID: Xoed+58lAaef I dont think we need to compare things here. Of course we should be able to make lives easier for reviewers and contributors. There is no need here to compare them. Remember that making lives easier for contributors will make lives easier for reviewers too after all :) Because more correct pathces and more people wanting to be involved. Hence me saying its not a comparison or focusing on one or the other. But more of the same thing. As I mentioned in another point in the thread we already have "non-standard" stuff so that argument doesn't really hold water here. Non standard stuff being emacs, mumi and a bunch of other stuff that make submissions tolerable. Or emacs-debbugs. Also yes "visual" flow helps some people. Nothing wrong with that and we should encourage that. (Encrourage that by fully supporting it). I mean i a= m trying to use the cli as less as possible since its a horrible interface. And yes the gnu commit messages could be improved. Its not like they are set in stone anyway. MSavoritias Giovanni Biscuolo writes: > [[PGP Signed Part:Undecided]] > Hello Katherine, > > thank you for having summarized (part of) this thread in a list of > actionable tasks > > now Someone=E2=84=A2 have the chance to decrease the cognitive overhead f= or > contributors by _increasing_ her cognitive overhead to sort out and > complete each task > > as a general comment, it seems to me that you put very much attention to > the process of contributing v1 of a patch but you underestimate the > cognitive overhead of the collective patch reviewing process and > committing to Guix proper process > > AFAIU, observing what is happening in Guix since 2019, what is actually > critical for Guix is _not_ the cognitive overhead needed to send a patch > to guix-devel, but what comes after and _around_. > > last but not least, to be fair we should see at what other distribution > (not single software projects) are doing for their contributing process: > I know a little about Debian and in my experience it's far easier to > contribute to Guix than to Debian (but I know little, I emphasize) > > Katherine Cox-Buday writes: > >> Summary of my conclusions: >> >> 1. We should use sourcehut or continue to improve mumi > > Please forgive me if I insist, but the one and _only_ benefit of using > SourceHut is the web-UI /helper/ to prepare an email message to send, > it's "just" a web-UI version of the "git format-patch" CLI; the rest of > the "patch management workflow" is email **and** CLI (git am) based; > it's documented. > > Furthermore, users that are comfortable with the SourceHut web UI are > free to use that as their personal working repo, there is no need for > Guix to use a SourceHut remote as the official one. > >> =C2=A0=C2=A0 - QA status should be visable from a patch's page > > On mumi web interface, in each issue page related to a patch, there is a > "badge" linking to the QA status for that patch, right below the issue > title; i.e.: > > https://issues.guix.gnu.org/65694 > > have a link to https://qa.guix.gnu.org/issue/65694 > > QA (and relates services, like data.qa) is a great project that could > greatly improve current situation when completed! > >> =C2=A0=C2=A0 - It should be possible to interact with the issue through= the >> page > > I don't exactly understand: what do you mean with "interact"? > > ...and what page? https://issues.guix.gnu.org/ or > https://qa.guix.gnu.org/issue/65694 (or any other issue) > >> 2. We should create scripts/sub-commands to lift contribution activities= =20 >> into >> =C2=A0=C2=A0 higher-order concepts: >> =C2=A0=C2=A0 - Prepare a new submission >> =C2=A0=C2=A0 - Run pre-checks on a submission >> =C2=A0=C2=A0 - Submit a patch >> =C2=A0=C2=A0 - Status of patch > > AFAIU you already use some of this "lifting" scripts od commands: can > you please send patches so thay could possibly be included in Guix > proper or in some section of the Cookbook? > > [...] > >> On 8/28/23 4:17 AM, Simon Tournier wrote: > > [...] > >> > In order to be pragmatical and list actionable items, could you >> > specifically list what you consider as a toil or cognitive overhead? >> > Maybe you could share your script helping you. >> >> Yes, great point! Let's try to distill all this conversation down into t= he >> salient points and see if we can't agree on some actionable items. >> >> Here's my understanding of the process to contribute a patch: >> >> =C2=A0 1. Check out main, and run `./bootstrap`, then `./configure=20 >> --localstatedir=3D/var --sysconfdir=3D/etc` >> =C2=A0 2. Run `make` >> =C2=A0 3. You need to determine whether the change can be targeted agai= nst=20 >> main or >> =C2=A0=C2=A0=C2=A0=C2=A0 needs to target a feature branch, so you go re= ad about that. > > [...] > >> In other projects I've worked with, steps 12-19 are commonly done in a CI >> pipeline, and courteous people will try to save CI resources by running= =20 >> these >> steps locally first using some kind of environment identical to what CI = runs >> (sometimes a container is used for this. I think Guix has better options= !). >> Sometimes this is not feasible due to asymmetric resources. But having t= he >> option to let CI manage this process is very nice. > > AFAIU this is where https://qa.guix.gnu.org/ is intended to help, but > now is not working as intended AFAIU > >> For me, steps 20-23 are bothersome. There's a lot of "if" statements=20 >> that lead >> to branching operations, and a lot of commands and flags to get >> right. > > oh yes, CLI is a cognitive overhead sometimes, so we need better > interfaces, some have found them > > actually, point 21 "Run `./pre-inst-env ./etc/teams.scm cc-members > ` to get the CC flags for Git" is bothersome and we should find a > way to better integrate that in "git format-patch" (so that will be > automatically used in all the git interfaces we use) > >> The extra step to get a debbugs ID is annoying. > > have you tried mumi CLI with the new feature? > >> If I compare this workflow to the workflow of other contributions I make: >> >> =C2=A0 1-10 as usual >> =C2=A0 11. Write a more commonly accepted commit message with no specia= l=20 >> formatting. >> =C2=A0 12. Run `git push` (subsequent changes are still just `git push`= ). >> =C2=A0 13. Go to forge website, click button to open a pull-request. > > Forgive me if I insist: that forge site is _not_ SourceHut > > Second: each forge web site have a custom (not standard) way to manage > pull-requests. > > Third: git have a pull-request mechanism [1] that could _easily_ be > integrated in each and every forge, allowing projects to use > /interoperable/ email based pull-request workflows if they want to. > > [...] > >> I don't find difficult, and reflected on the difference for awhile, I=20 >> think, at >> least for me, the highest friction comes from: >> >> - Steps 11-19, or (to assign it a name for easier reference) the "CI >> steps". > > OK: AFAIU https://qa.guix.gnu.org/ is _the_ answer, so we need more > contributors to that project > > ...and this means more cognitive overhead for Someone=E2=84=A2 :-) > > [...] > >> If we wanted to encourage contributors to run "CI steps"=20 >> locally before >> =C2=A0 submitting, maybe this should be another `guix` sub-command? `gu= ix=20 >> pre-check` >> =C2=A0 or something? I know there is a potential contributor who had th= is=20 >> idea first >> =C2=A0 who would want to hack on this. > > Having such a sub-command maybe could help, maybe not, because IMO the > core and most cognitive challenging steps of all "CI steps" are not if > builds are done locally or not but (in order of importance): > > 1. having patches reviewed by humans, the "not automatable" part because > Someone=E2=84=A2 have to understand the _meaning_ of the patch and verify= it > conforms to the coding standards of the project, including "changelog > style" commit messages; > > 2. understanding why build derivation fail when it fails. > > This is real cognitive overhead and this cannot be automated. > >> - Steps 19-23, or the "manage patch" steps. >> >> =C2=A0 I think an insight here is that the big button on forges is actu= ally=20 >> a program >> =C2=A0 removing the mental overhead for you. > > On the "web forges" vs "email based" patch workflow management I've said > enough in other messages in this thread, here I just want to add > (repeat) this: please do not only consider the mental overhead of > potential contributors for "managing patches", also consider the mental > overhead for patch reviewers; I've read many articles from professional > patch reviewers that perfectly explains the great advanteges of using an > email based workflow > > [...] > >> =C2=A0 I also don't usually have to worry nearly as much about crafting= a commit >> =C2=A0 message. So long as the title is under a character limit, and th= e body is >> =C2=A0 helpful, it's OK. I think what bothers me most about the GNU cha= ngelog >> =C2=A0 messages is that it's the worst of both spoken language and prog= ramming >> =C2=A0 languages: there's an expectation of structure, but no grammar I= can=20 >> parse >> =C2=A0 against, and it's free-form. > > I'm sorry that the GNU policy about commit messages bothers you (on the > contrary it makes me happy); please consider that thai is /just/ one of > the policies of the Guix project: code of conduct, coding standards, > others? > > [...] > >> - Having multiple places to manage aspects of my patch >> >> =C2=A0 In a web-forge, I generally have a URL I can go to and see every= thing=20 >> about my >> =C2=A0 patch. I think we have that with https://issues.guix.gnu.org wit= h two >> =C2=A0 exceptions: (1) QA is a click away, or if you're using email, yo= u're=20 >> not even >> =C2=A0 aware that there's a QA process failing (2) If you're not using = email, >> =C2=A0 context-switching between this page and email to respond. > > it's "just" an _interface_ issue > > [...] > > Happy hacking! Gio' > > > [1] https://www.git-scm.com/docs/git-request-pull