Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/13/23 18:42, Maxim Cournoyer wrote:
> Hi Fannys,
>
> Fannys <email@fannys.me> writes:
>
> > Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> >
> > > > > This is what I mean when I say many times emacs is kind of mandatory,
> > > > > and
> > > > > this thread is kind of a demonstration of what I meant because the main
> > > > > discussion evolved to: you can use this or that in emacs to ease the
> > > > > dev
> > > > > experience.
> > > >
> > > > One of the benefits of my being able to attend Guix Days was seeing
> > > > peoples' workflows and stacks in person.
> > > >
> > > > As such, one of my conclusions having (already) committed to Guix was
> > > > that I needed to master Emacs prior to Guile
> > > > (Im highly flow orientated).
> > > But again, even if this is a great option for you, it might be a really bad
> > > option for some other people. Everybody does not have the time to spend
> > > learning emacs, or other specific tool. It's ok if the workflow suggests that
> > > but it's not great if we have no other alternative.
> > >
> > > It's not accessible and imposes a barrier in some people.
> > Yeah agreed. And we should be consious of that.
> > Ironically by mandating Emacs and Email we force people to use specific
> > tools while at the same time even though the same people will complain(!) 
> > against vendor lock-in
> > like github.
> 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.
>
> 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).
There are two problems here though. Let me elaborate:

1. The "recommendations": (This is just an example)

I am a new person wanting to get involved or just tweak my config in 
guix/guile.

I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management

Apparently i have to either use the terminal or something called emacs. 
If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation

It says to install emacs-guix. Okay. So apparently it is an Emacs thing, 
whatever that means. And when you start Emacs after installing the 
package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to Emacs 
then. The other thing is the terminal apparently. Horrible, but at least 
it works.

So what if I want to mess around with guile and the guix config directly?

If we check here it says to use something called Emacs again. So Im 
guessing its the same Emacs that was also apparent in the previous step 
with the config. but not there are more tools.

2. The contribute yourself your tools.

My point with all this is not to say its your fault or really anybody 
specific. Its more to say that:

Recommendations in an abstract sense work fine. But not in the real 
world. You proposed:

> 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). 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).

How many people actually have the time and energy and know-how to do 
this? In the original email it was about a mother who on her spare time 
contributes to guix. Or as another example it could be about a person 
that just starts programming. Or it could be about a person that works 
and has few spare time.

Of course I saw in an email earlier in the thread that: "If you don't 
have time (as I do) then don't contribute." Which at the very least i 
find gross and not at all what guix is about.

Guix is supposed to be about equity. We are not all privileged (not 
saying you are or anybody else in this thread is.) enough to have the 
time and knowledge to learn Emacs, git-mail, find an email client that 
works (still havent found one. previous email was with the wrong email 
and threads are a nightmare.), and set up geiser and such.

The reason I have come to guix is because it strives to actually make it 
easier for people to change things. with guix shell and such. So making 
it easier for people to contribute is absolutely a part of it. Im not 
saying we should force every volunteer of course to do "work". What I am 
saying is:

- Guix recommendations in the manual, in the cookbook and other places, 
carry weight. In the sense that if to use something else than Emacs i 
have to write my own scripts or go to some random tutorial in a search 
engine then we have effectively pushed Emacs as the main guix platform. 
For better or worse. And we have excluded a portion of contributors. 
Same with email, debbugs. What can solve this is effort to actually 
include people.

Visual Code as you mentioned or any other editor, or mumi, these are all 
efforts to get contributors in the first place. The contributors will 
never come and create the infra and tooling they want by themselves. It 
takes some initial effort on our part to lower the barrier and 
"cognitive overhead" as in the title to actually encourage people to 
contribute. Same way that women or other minorities dont just "show up" 
to change the culture to make the welcome. they would rather go where 
they are already welcome.


Not to make this too long i strongly disagree that "Create your own 
toolbox" is a barrier we should have for new users. And recommendations 
carry weight because its what people see the community putting effort 
into and using.


Some proposals/good directions that we already have not to leave this 
with just complaining is:

- Improve guile studio and add it as a recommendation. With an improve 
UI and keybindings for it.

- Improve the docs of course.

- add more editors maybe(?) by ourselves.

This is for the starting to change guix/guile code that is. For people 
wanting to use code there is others. As there is for actually committing 
being discussed elsewhere for improvements.


Yes I want to help on all of them at some point :)


MSavoritias