unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: The e(macs)lephant in the room and the Guix Bang
@ 2023-09-23  5:19 Nathan Dehnel
  2023-09-23  7:37 ` Janneke Nieuwenhuizen
                   ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Nathan Dehnel @ 2023-09-23  5:19 UTC (permalink / raw)
  To: atai, guix-devel

________________________________

>Hi, for some reason emacs has become the elephant in the room of the
discussion on contributing to guix.

>Regardless of one's opinion of emacs, I just want to add that this is
itself strange.  I have contributed some (package definition) patches
to guix, all without using emacs.

>I am not an emacs user, so emacs is not necessary for contributing to guix.
For what it's worth, the emacs-motif package in Guix was my addition.
I don't use it myself.

I don't use emacs either (because it's so impenetrable), so I just use
kate instead, which isn't a great environment for me either. It has
rainbow parens, but it doesn't balance them, which is a hassle. I keep
using it though due to lack of time to browse through alternatives. I
heard about guile-studio, but it doesn't appear to have a dark mode,
and I imagine trying to add one would require a bunch of emacs-style
screwing around with it.

https://archive.fosdem.org/2022/schedule/event/lispforeveryone/
This is the only setup for coding in lisp that has actually looked
attractive to me. (Coding in wisp with colored blocks that transpiles
to s-expressions) Though I haven't had the time (and probably
expertise) to set it up for myself.


^ permalink raw reply	[flat|nested] 31+ messages in thread
* Re: The e(macs)lephant in the room and the Guix Bang
@ 2023-09-20 18:00 Andy Tai
  2023-10-02 14:56 ` Ludovic Courtès
  0 siblings, 1 reply; 31+ messages in thread
From: Andy Tai @ 2023-09-20 18:00 UTC (permalink / raw)
  To: guix-devel

Hi, for some reason emacs has become the elephant in the room of the
discussion on contributing to guix.

Regardless of one's opinion of emacs, I just want to add that this is
itself strange.  I have contributed some (package definition) patches
to guix, all without using emacs.

I am not an emacs user, so emacs is not necessary for contributing to guix.
For what it's worth, the emacs-motif package in Guix was my addition.
I don't use it myself.


^ permalink raw reply	[flat|nested] 31+ messages in thread
* How can we decrease the cognitive overhead for contributors?
@ 2023-08-23 16:25 Katherine Cox-Buday
  2023-08-24  6:33 ` (
  0 siblings, 1 reply; 31+ messages in thread
From: Katherine Cox-Buday @ 2023-08-23 16:25 UTC (permalink / raw)
  To: guix-devel

Summary: for people who don't contribute to Guix a lot, each 
contribution has
very high cognitive overhead. Can we work to reduce that?

Hey all,

Contributing to Guix is currently pretty difficult for me. I'm a Mom with a
full-time job, and anything outside of my job that requires a lot of 
executive
functioning (e.g. lots of manual, detailed, steps) is very difficult for 
me to
get correct. That last part is what I wanted to discuss, because that's 
the part
that prevents me from contributing more than I do, and I think there are
probably others whom are impacted by this.

When I have some time to contribute, I usually stall out at the "submit 
this for
review" because of the amount of cognitive overhead required. I've written a
script for myself that tries to perform all the steps including running 
the git
command to submit the patch, and this has helped me, but that this is 
necessary
for me to do might be something that, if addressed, could help others.

Here are some examples of things that cause issues for me. This is not a 
list of
grievances; it's my way of attempting to demonstrate the "shape" of the 
issue:

     I signed up on Savannah with the intention of applying to be a 
committer.
     Savannah closed my account one or two days later due to inactivity.

     I can't ever seem to get the GNU style commit messages correct. I 
use the
     templates provided, but those don't cover all cases, and I've even 
gotten
     feedback in a review to change a message it created.

     I don't use the email-based patch workflow day-to-day, so this is 
another
     area where I spend a lot of time trying to make sure I'm doing things
     correctly.

     My script runs `guix style` and `guix lint`, but its suggestions aren't
     always correct. I suspect I've submitted some patches with nonsensical
     changes due to implicitly trusting these tools.

     Maybe 
https://lists.gnu.org/archive/html/guile-devel/2023-02/msg00030.html
     addresses this, but manually managing Guile imports is laborious. As a
     fledgling schemer, I often forget which imports I needed just for
     development.

I think I would summarize the core of these examples as:

     "At every step of the contribution process, I must manually check that
     multiple things are correct. With limited available executive 
functioning,
     and no automation, this is very difficult to do correctly, and an 
easy place
     for contributors to stop."

I think that if I were working on Guix more frequently, I would build 
habits I
didn't have to think about, and these wouldn't be the large issues they are
for me. But because of the nature of a project like Guix, we want 
contributions
from people of all kinds of backgrounds, not just people who have the 
privilege
to work on Guix a lot.

I have given a list of issues to a group of people who are presumably
analytical, and I think the natural inclination is to go point-by-point 
and make
arguments for/against. Instead of that[*], I invite you to address the more
abstract issue: (should/how do) we reduce friction for making contributions?

Here are some things I've considered:

* Contributing to Guix is not for you

     I would be really sad if someone ever said this, but I guess it's a
     possibility. Maybe someone like me just can't be a contributor to 
Guix until
     I have the bandwidth to manage all the details. I would 
preemptively argue
     that diversity of thought and experiences usually leads to better 
things.

* It's OK to make lots of mistakes

     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've 
made. I
     also want to become a committer, but I don't know how that would 
work if
     I'm regularly making mistakes. Obviously people would still be 
reviewing my
     commits, but presumably a committer should not regularly be making
     mistakes.

* We could support a managed web-based workflow

     I think this has been brought up a lot of times, and I don't have a 
clear
     idea of what's been said. But I think a lot of developers these 
days are
     more familiar with this style, and we could still maintain 
self-sovereignty
     if we hosted something.

* Encourage upstream communities like "Guix 'R Us" 
(https://sr.ht/~whereiseveryone/guixrus/)

     Maybe Guix proper continues as is and we foster various upstream 
communities
     that utilize different styles and batch their contributions?

What do you all think? Does this affect anyone else?

[*] But if you have workflow suggestions, I'm all ears!

--
Katherine



^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2023-10-02 14:57 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-23  5:19 The e(macs)lephant in the room and the Guix Bang Nathan Dehnel
2023-09-23  7:37 ` Janneke Nieuwenhuizen
2023-09-23  8:58   ` paul
2023-09-23 10:00     ` Janneke Nieuwenhuizen
2023-09-24  7:37       ` Nathan Dehnel
2023-09-24  8:51         ` Liliana Marie Prikler
2023-09-25 11:19           ` MSavoritias
2023-09-25 18:54             ` Liliana Marie Prikler
2023-09-25 19:21               ` Simon Tournier
2023-09-25 11:09       ` MSavoritias
2023-09-25 20:34         ` Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang) Simon Tournier
2023-09-28  7:19           ` Efraim Flashner
2023-10-02 11:23       ` The e(macs)lephant in the room and the Guix Bang Munyoki Kilyungi
2023-09-23 12:59     ` The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang) indieterminacy
2023-09-25 11:13       ` MSavoritias
2023-09-25 20:35         ` Simon Tournier
2023-09-26  7:33           ` indieterminacy
2023-09-23  9:56 ` The e(macs)lephant in the room and the Guix Bang Ricardo Wurmus
2023-09-23 10:25   ` Ricardo Wurmus
2023-09-23 12:29   ` Ricardo Wurmus
2023-09-24  7:11   ` Nathan Dehnel
2023-09-24 20:19   ` Csepp
2023-09-24 21:46     ` Ricardo Wurmus
2023-09-27 18:38 ` Christine Lemmer-Webber
2023-09-28  6:12   ` Nathan Dehnel
  -- strict thread matches above, loose matches on Subject: below --
2023-09-20 18:00 Andy Tai
2023-10-02 14:56 ` Ludovic Courtès
2023-08-23 16:25 How can we decrease the cognitive overhead for contributors? Katherine Cox-Buday
2023-08-24  6:33 ` (
2023-08-26  0:39   ` Katherine Cox-Buday
2023-08-27  3:22     ` Maxim Cournoyer
2023-08-27  7:39       ` 宋文武
2023-08-28 11:42         ` Giovanni Biscuolo
2023-09-01 19:12           ` Imran Iqbal
2023-09-03 17:45             ` Ekaitz Zarraga
2023-09-03 21:05               ` indieterminacy
2023-09-03 21:16                 ` Ekaitz Zarraga
2023-09-13 12:20                   ` Fannys
2023-09-13 15:42                     ` Maxim Cournoyer
2023-09-17 11:29                       ` MSavoritias
2023-09-18 10:09                         ` Simon Tournier
2023-09-19 16:35                           ` The elephant in the room and the Guix Bang Giovanni Biscuolo
2023-09-20  8:21                             ` Csepp
2023-09-20  8:45                               ` The e(macs)lephant " Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-09-20  9:28                                 ` MSavoritias
2023-09-20 14:03                                   ` Ricardo Wurmus
2023-09-20 14:09                                     ` MSavoritias

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).