guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sarthak Shah
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Thu, 14 Sep 2023 23:19:12 +0530

I think that quite a few Guix users end up not committing to Guix because of how daunting and strange the process seems.
In particular, having an alternate, easy-to-use interface for updating package definitions specifically could be very useful.

The greatest strength of Guix is that it can be very easily integrated into Guile programs.
I believe that it should not be very hard to create a user interface (web, ncurses or GUI) that searches for a package's location (the package record has a field that accommodates this) and then displays it, which the user can then edit. We can then have the program build the package based on this new definition, and if the user is satisfied with it it can format a patch based on the edit and all the contributor will have to do is e-mail it.

This could greatly reduce the barrier to entry for contributing newer package versions, but it could also open up the door to spam/misuse if we host it on the web.

Regards,
Sarthak.

On Wed, 13 Sep, 2023, 17:54 Fannys, <email@fannys.me> wrote:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]