From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 6IVUH21CAmV8NAAAauVa8A:P1 (envelope-from ) for ; Thu, 14 Sep 2023 01:14:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 6IVUH21CAmV8NAAAauVa8A (envelope-from ) for ; Thu, 14 Sep 2023 01:14:53 +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 054A6CAEF for ; Thu, 14 Sep 2023 01:14:53 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=protonmail2 header.b=IBf9I8XF; dmarc=pass (policy=none) header.from=elenq.tech; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694646893; 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=9NulkBL/MmyOOFWe7nljnOtBuoh6h6MS4KsoAi6G414=; b=p6h7EQR68xvWECgVem4hgZ9MIzqlWftA89pya7hTReCwPsscd1bb5nWscdBld9n+xqTW9f EbQ2/XI1htig/OnDyb2/4xZKSOc0plcYvTBPXdihGq5TIgbLcx7EW48n+zLEdrpesnqbiH 9a9bHT66clg6b3kKj9KHrE8TO2wEqjJ30axyKSOenk7CZicdSaQlO/6A9kTpwcZmGHACQp DrCy9FU4vJfQEJHY/c/dP4G7OBJVBFxoWoMURLma3jlui+ybQwA/UDj09V2npW9KSPx9DJ ZVCSWg6YqMwMe1JvWnoc3OQ7Lcz5oAMN7NzRvW+75TF9kc59h8o5Fy30ilOJBQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694646893; a=rsa-sha256; cv=none; b=Kn/deGrAOrovNbAErPTpNcpJcJvnpZnQlTi8CTYOxX3ARQrT8YtXBuSIW29holqFGHorqD I72qpjTlD3RVZifYfqY9JO8gb4TvsG8h2RCf4nVs+34BMhKn3lG3o5FelAsU40aztEPBBI +P7bvFFmaxdGPp5vFWdv0UP/Kdl1Z3HwSleg+rAnhPYTNDr+Aviuhf/Ul689g3iPXiuY/j K/vhZjxEeSGrTRm232Of0Gd99mAStvb7z3QqIDeIVOOszAZf5H4UGoj6ekiLPP8UQ4KfO/ 15xKP8+g5V7eFXdMwluYnDXnMNOrwk2EVLvZg2AD3rZRtxR6HDzGocLK/Sjrmw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=protonmail2 header.b=IBf9I8XF; dmarc=pass (policy=none) header.from=elenq.tech; 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" Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgZ3r-0006MP-AX; Wed, 13 Sep 2023 19:14:19 -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 1qgZ3o-0006MG-Vp for guix-devel@gnu.org; Wed, 13 Sep 2023 19:14:17 -0400 Received: from mail-4317.proton.ch ([185.70.43.17]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgZ3l-0006fn-QV for guix-devel@gnu.org; Wed, 13 Sep 2023 19:14:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elenq.tech; s=protonmail2; t=1694646849; x=1694906049; bh=9NulkBL/MmyOOFWe7nljnOtBuoh6h6MS4KsoAi6G414=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=IBf9I8XFSEGaMu+Zow9XBJMmPRLu7ReTqFFQDoXAh8Wcukh3Aiwx03N6tsfsgnroZ mpfxrDDJ9h4CIMHK546S1A/DZTqqBeBnO+Bwtt3fIj4x6Ppv5myigYTc0ZSsX0IYIV XTEpcLqWHbBMlIeLD6h+dSWILBkC5AANVkFvMu68Rm1WC0iKedP6KhiPOUVQrYVAkP bamXcoWtkUzHjLhf9sZOd1jQobgB7Tl9bsSw3tGc0iG1KoO8+Yv+3A7uHSSq8X9zYd L7rfxw6mJeEVhKAeJD8OQLKNWaspYAH99unjZk0YTOkSAk+KkVOQ110bGMyYThnfk0 vfChGIlvfsuOQ== Date: Wed, 13 Sep 2023 23:13:55 +0000 To: Maxim Cournoyer From: Ekaitz Zarraga Cc: Fannys , indieterminacy , Imran Iqbal , Giovanni Biscuolo , =?utf-8?B?5a6L5paH5q2m?= , Katherine Cox-Buday , "(" , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? Message-ID: <3ZzU4zgFwkPOloaAUEzOVfPymzXwjBhOjhx1Mswk70ECBTdx7GDr7R1EsIpcyVaXBDDyTTbF9rAXwCFGnwBJjZYSNIqXNw3VgI5pfD_Z2tg=@elenq.tech> In-Reply-To: <87cyymw046.fsf@gmail.com> References: <87a5udaq7q.fsf@envs.net> <87il8z9yw8.fsf@xelera.eu> <8c30655ca9905946fc718940700f2475@libre.brussels> <871qf2tg6u.fsf@fannys.me> <87cyymw046.fsf@gmail.com> Feedback-ID: 3263582:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.17; envelope-from=ekaitz@elenq.tech; helo=mail-4317.proton.ch 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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-Spam-Score: -1.98 X-Spam-Score: -1.98 X-Migadu-Queue-Id: 054A6CAEF X-Migadu-Scanner: mx0.migadu.com X-TUID: +Y5xK0y/y4CY Hi, On Wednesday, September 13th, 2023 at 3:42 PM, Maxim Cournoyer wrote: >=20 > There's no lock-in. You can use any tool you want. Most people hacking > on Guix do so with Emacs and Geiser because these are currently the best > tools (that I know of) to do the job; these are the tools many of us > know and can easily recommend. If Visual Code (or editor X) was > packaged in Guix and had great support for working with Guile, we could > also mention it in our manual or in the cookbook. >=20 > Notice I use recommend rather than mandate; these are just > recommendations that try to be helpful. If it's not helpful to you, you > are free to select your own tool box and share how it works (via patches > to the contributing section or a blog post for example). Of course, but it's limiting because there's no other recommendation than t= hat. Everything is built around it with no sensibility to any other approach. Many times I've been answered how to solve my problems using emacs and a bi= g part of this conversation evolved in that direction, proposing technologica= l solutions to human problems in emacs, and only for emacs, ignoring the fact that many guix users are not emacs users and also that technology is not th= e root issue of this. If you have a hammer everything look like nails I guess, and we are programmers, there's nothing shameful about that, but if we really want to = be welcoming we have to be more than just programmers. Maybe that's something = not all of us should do, but some. I don't know. Further than that. I'll try to summarize my views on this because I think w= e diverged a lot in that direction and it would be a shame to miss this opportunity to be more welcoming. ## Boring stuff coming, you have been warned The technology itself is not a real deal most of the times. Sometimes it ca= n be: should I recompile the project? How do I configure the development environment? Why my setup has to be a little bit worse if I'm not working w= ith emacs? How do I contribute my patch with the email provider of my choice? C= an I just paste the patch in the body of the email? Maybe attach it? Which one i= s better? One patch per email? Maybe I'm bothering people asking the same thi= ng over and over again? Most of those are a matter of getting used to some things that might be har= d at the beginning. I'm sure Katherine, who started this thread is not really limited in a technical level, as I am not. We might be limited in the amoun= t of time needed to get used to these things and we don't want to bother maintainers and commiters with stupid errors we feel like we are committing over and over again because we don't have a solid reference for some of the= se things. Examples of missing pieces of information: > If you can't use `git send-mail` for a reason you can do this and that an= d > that instead. > If you are not an emacs user you can try this and that. (*probably this i= s > something we, non-emacs users, should write*) Example of a good way to do it, (maybe it's missing a reference in the docs= ): https://guix.gnu.org/en/blog/2021/the-big-change/ Political/management decisions often more complex to deal with. Changelog s= tyle is, in my opinion, useless, but it's not hard to follow if there are good guides on how to do it well. There are other changes in the way packages ar= e described that are hard to follow too. Just copying what other people did i= s not enough, probably because we don't feel like we can control what we are doing. It's some kind of a trial and error process that always ends up in t= he hands of the commiter or maintainer that receives our patches. My take is: *check what other packages/commits do* is not a real answer. Th= e same way reading some English is not enough to write English yourself comfortably. We need guidance or clearly written stuff that is *easy* to fi= nd. Most of these questions are answered in the mailing list, the same way I th= ink Liliana very well explained how Changelog commits have to be done, but it's= not written in Guix itself (there's a link in the manual) by Guix and *for* Gui= x. I would prefer to use other kind of tooling. Sourcehut is interesting as it provides a way to keep the same email based approach we use, but with some extra goodies, but I'm also OK with what we currently have. So that's not a= big deal for me at this point. I can say I'm starting to get used. If we had a *very clear* guide, that would be way better for contributors. = Not just about Guix, but about all those other things that happen around. And I don't mean a copy/paste tuto, but something were decisions are explained wi= th the goals they have. (As a note, the GNU Standard for Changelog commit messages has some example= s that are way more verbose than the ones we have in Guix. IMHO those have a = lot of sense, the commit messages we do in Guix most of the times don't.) The final point I would like to insist on is the contribution experience. I don't really know how the issue system works as a whole. We have issues tha= t are ages old, and new issues are opened every single day... This *must* be superfrustrating for maintainers. Currently I use https://issues.guix.gnu.o= rg/ to track some of them, but it's not easy to follow at all. You have been talking about mumi a lot in this thread. To be honest with yo= u, I had a hard time trying to learn what it actually is and how to start using = it and I even gave up with it. That's not a good contribution experience. I ju= st felt like just sending a couple of patches from time to time is enough for = me and I can manually use email for that. Also as I already said, there are many patches that are forgotten forever, = I contributed with a build-system more than half a year ago and I got no answ= er from anyone. It's a change that doesn't affect the core of guix at all, and it's better merged than not. It could just be merged and keep an eye on how does it work in the wild and wait for other contributions. It's a little bi= t frustrating, and as I already mentioned it also has to be frustrating for t= hat maintainer that would love to review what I sent and has no time for it bec= ause of all the patches that should be corrected because stupid problems people commited because the process is not really clear. I don't know. I'd also love to be a commiter, help a little bit more, but I think there's= a knowledge barrier I feel I will never cross. I'm quite comfortable doing ma= ny things, but I think I can't learn anything else. The only ray of hope I hav= e is the article series Unmatched Paren is sharing in the Guix blog (thanks). It's also discouraging to have questions and never get answers for them. Fo= r things that should work and are broken. It gives you the feeling that everything is fragile, and there's no way to fix. The only computer I work = on is Guix, I am invested on this, but sometimes for work reasons I feel I wou= ld need to abandon it, as many things that should just work are basically usel= ess and I can't fix, even if I'd love to. Example: > I just want to build a program for arm-none-eabi, for gods sake! Every > variable is set up properly... What am I missing? What could I possibly b= e > missing??? Probably, if we had an easier contribution process, these secondary problem= s would just become slight inconveniences, which is what they often are, but = some days they hit really hard. This is what it feels like. Sometimes. Most of the times, though, it feels Guix is really awesome, that you people= are amazing and I'm really happy to be part of this. I can only be thankful of being a tiny part of this amazing piece of softwa= re and all I've learned in the process. We can do better, but that's no reason to forget all the good things we hav= e. Cheers, Ekaitz