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 ANl4Ic3x52RwIwAASxT56A (envelope-from ) for ; Fri, 25 Aug 2023 02:11:57 +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 gHhUIc3x52Rn4QAAauVa8A (envelope-from ) for ; Fri, 25 Aug 2023 02:11:57 +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 0A91270C77 for ; Fri, 25 Aug 2023 02:11:56 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=protonmail2 header.b=Z7AUNITC; 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=elenq.tech ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692922317; a=rsa-sha256; cv=none; b=SW75c0DCwHdwvGomXnql7UPrwLpe6Aj4P5mYv4tBdXQSpYU6ks+zoOw/nSUoLPqCfazLWG L1TujXRlSMF1GPJGwBWzIsDSe3z2ki/KMHtgbUdXAkTE8p0u4kZY7yEE5IxyKeCDL6WwJU ngSiJWVN8pdS6s6VHF1y92DNMEN97KWB0B6um/Lrd9XdmDVJLsr/4k8C/oY9YL6P4PDixQ 04AAEBzjRG+tjJSYAn5SS/LApUB9gREAu7Myz+U77eCf2cX1ysSMqEbjVjDeysLofUlyYE IFNieu5c0PwI5TFdO0giQ5mCJGJgmG0rQwmmZfYbxdoBelbMb3xhltO7elVoyg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=protonmail2 header.b=Z7AUNITC; 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=elenq.tech ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692922317; 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=4A5ZfG6gnIPDJwLUgJBSS8KFuQoZzwpGsom6A4TN/ww=; b=otnhBtrz/qjgkxj3GU4EohBr9Be6zV6TJxTyC3Qj4BlMe+4aH8cIYMRC6PLz+OrfcYt1eK C5EcRs0V3E4B5kcoQOZpvGPPaF2Tsw/hMVtHc1mQfKsfA8Sd4MCnVa6HLUuVCj/b6h0Ks2 GSvI9qFJ/G98ek9dMXc3zOu+2wKpP2+9lO8UQgHPXYsqEe3y5NqeuJ97s/LtDbHmLjQ2HZ aYk69jIkYpFx63rlwTRGr8HhYzhtXobfsgxgwW+loAbkkwHBLhXWk6IYWpsmipW03Vt/UN WUvdn9sQZ0yLZRmu3DMqrrIIFA7Xdo0Dvnkpb28yNqz97KUMwlgf1dXjcWB8MQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZKPx-0001mv-CB; Thu, 24 Aug 2023 20:11:13 -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 1qZKPv-0001mR-26 for guix-devel@gnu.org; Thu, 24 Aug 2023 20:11:11 -0400 Received: from mail-4018.proton.ch ([185.70.40.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZKPq-00020M-86 for guix-devel@gnu.org; Thu, 24 Aug 2023 20:11:10 -0400 Date: Fri, 25 Aug 2023 00:10:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elenq.tech; s=protonmail2; t=1692922262; x=1693181462; bh=4A5ZfG6gnIPDJwLUgJBSS8KFuQoZzwpGsom6A4TN/ww=; 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=Z7AUNITC5+pCT85DPKn7o1Nwro7a7kfhShu6CcyxTL8zHyVnUevl2dD/lwke9NlUF 9oALh7kwHaEVChFCt31OEphx0Zl4Kv6/u7ulWzsA2hcf771/TBmFLW3CXiIyvWVlac YvQgBndYDfbpjG4NFQV/td3g14FiDelE/7Ts/RcMqvb5c3pwtV9YK9qArsDBJJXdu4 byQn4lnjeR9H6/yedhU6wApDUpscAEmnb3NyuvY+ERCTV9A1XTGC7OziDHRwC1B7ed DYmTHKnlwo4hyNbLyqR0ZXpF16+k1mqgDXKu4VW+mOMKd08JFwKi8r6DtNT4kQJg9D rtXBocLnTq5fA== To: Csepp From: Ekaitz Zarraga Cc: Katherine Cox-Buday , guix-devel@gnu.org Subject: Re: How can we decrease the cognitive overhead for contributors? Message-ID: In-Reply-To: <871qfsayyx.fsf@riseup.net> References: <871qfsayyx.fsf@riseup.net> 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.40.18; envelope-from=ekaitz@elenq.tech; helo=mail-4018.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-Scanner: mx0.migadu.com X-Spam-Score: -4.91 X-Migadu-Queue-Id: 0A91270C77 X-Migadu-Spam-Score: -4.91 X-TUID: ZOx8Eqac+1+6 Hi, > This definitely falls into the IDE tooling issue that I complained about > a bunch of times. There seems to be a reality distortion field around > Lisp that makes some users believe that s-expressions automatically lead > to a good IDE experience. And yet, Java IDEs have had automatic import > management for at least 15 years (around the time I first used Eclipse), > but Guile still doesn't have anything of the sort. > It looks like the only way to move forward is for people to share these > helper scripts they've been using and forging them into a consistent > developer environment, maybe based on Guile Studio. Hopefully I can > make some contributions towards such a project. I fully agree with this. I'd also add that everything seems to be emacs focused and not being an emacs user is kind of an extra barrier for people. (I'm not an emacs user) > Lots of important use cases that > Guix could serve are ignored because the people who need them are not > represented in our community and/or they can't contribute and no one is > able/willing to write code for them. Yes, and even if you manage to write something yourself, many times you get now answer to your patches because no one else is interested on what you did. It's perfectly understandable but also discouraging. Example: I wanted to push Zig support in guix a while ago. Made a build system and got no answer. The feeling here is that the code proposed is not good enough, but I don't know how to improve it so I'm stuck. It would be great to feel comfortable enough with the code to be sure that it can be merged, but I can't find the resources to make it better. If it was clearer or if it was easier both sides, maintainers and contributors, would be more effective and happier. > > * It's OK to make lots of mistakes > >=20 > > The people who have reviewed my code have been generous both with their > > time and fixing my mistakes and then applying. Maybe this model is OK? = I > > still feel guilty every time a reviewer has to correct an oversight I'v= e > > made. I also want to become a committer, but I don't know how that woul= d > > work if I'm regularly making mistakes. Obviously people would still be > > reviewing my commits, but presumably a committer should not regularly b= e > > making mistakes. Exactly my feeling. And I've been working with Guix for a while... > In a sense I agree with this, but if mistakes are this easy to make, > then I think something is wrong with the project, not with the > contributor. Instead of making people learn tightrope walking, maybe we > should be building actual bridges. > Guix actually fares pretty well in this regard compared to some other > projects I tried contributing to (stares at Plan 9), but there is > still a lot of knowledge that experienced developers take for granted > and don't actually document. Writing new packages is mostly documented > well, but as soon as something breaks, you are thrown into the deep end, > having to dissect logs, bisect commit ranges, learn strace, gdb (which > still doesn't work well on Guix), learn how to compile packages with > debug info (and actually waste some more CPU time and IO on rebuilding a > package you already have), learn how to adapt docs from other distros, > etc, etc, etc. > I've been trying to document these at least for myself, but haven't yet > had time to put them together into something others could read. "As soon as *anything* breaks everything starts to fall apart" is a feeling I also have a lot. Many things in my system are poorly configured because I simply can't figure out how to fix. Default things work great, but when something doesn't you are exposed to a great complexity, there's almost no midpoint. Specially, some services feel like nobody use them because they have almost no options to be configured and there are no examples out there. I have to say it got better in recent months. We are doing achievements in this area, which is great. > By the way, that's another issue. Using a TeX based document format for > the docs is, uuuh, maybe not the best idea. Info is a pretty okayish > documentation reader, but it's a relatively big barrier to entry > compared to what you need to know to make a small edit to the Arch wiki. > This way mostly just experienced contributors write docs, not the > users who just want to document how they made some weird use case > possible. Again, I'd say this is because of emacs, again. It's not that bad, because = you can use the website, too, but collaboration in the manual is a little bit daunting. These are my five cents. Cheers, Ekaitz