Re: Guix wiki

[Attila Lendvai <attila@lendvai.name>]

what follows is some 0.02 from someone relatively new to Guix.


> > sending a patch to the manual is a way higher threshold than editing a
> > wiki, especially when it's someone's first contribution. and some
> > random, half-baked copy-paste doesn't belong in the manual, while it
> > may be very useful when found in a wiki using the search engine.
>
> This is where we disagree. I’ve wasted so much time in my life
> following outdated or wrong instructions on forums or wikis. I really
> don’t want to see anything half-baked anywhere near this project. There
> are few things that frustrate me more than well-meaning but misleading
> advice.


sure, this is a matter of taste.

although, it's one thing to get misguided with 1) informal
instructions, and another with 2) formal ones (i.e. a snippet of
runnable code that emits useful errors and backtraces when things go
wrong).

an obsolete instance of 2) can still be useful when all it needs is
just a small change to follow some renames.

ad-hoc example: a package definition demonstrates a complex technique,
but otherwise uses the obsolete pre-c-u-f merge input syntax, for
which the runtime warns/errors.


> I keep repeating myself: you don’t need to use debbugs. We do. Nor do


this is true to some extent when sending a one-shot patch to the
docs. but when i'm sending patchsets to the codebase, i do need to
learn at least the basics of debbugs. sorry for broadening the scope
here, but these are related.


> Before Guix I had never used Debbugs. I rarely ever contributed
> patches. I had no idea how to send patches via email. There was a time
> when I didn’t know that patches are generated with tools.


my point is that i know all these, and have been practicing them for
decades, and yet, contributing to Guix required a learning curve that
was higher than it's regularly expressed by people who are already used to it.

i do understand and accept the reasons (freedom, bootstrappability,
independence, etc), but i think the tools/infrastructure that Guix
uses for coordination is not very familiar to most programmers.


> No aspiring contributor needs to be fully formed before they are
> permitted to contribute. Get yourself a mentor within the project who
> can shepherd your contributions and make sure they find their way into
> the right files. Ping them if your contribution seems to have been
> forgotten.
>
> In my opinion, a public list of mentors that you can ask to charge of
> your contribution would be worth more than a mere info dumping site.


this sounds nice, but the reality is that nowadays reviewing and
pushing commits can take weeks or even months without much feedback. i
even have a fix for git-authenticate, coupled with tests that
demonstrate a hole, and it's been open for months. i assume because of
the lack of bandwidth from people who are in position to review and/or
push it, but whatever the reason is, this is the case.

the vision you are painting here is inspiring, but i think the Guix
community is reaching a size where such an organizational structure is
not facilitating the cooperation well enough. more and more random
people will show up, with contributions of varying levels of
quality. if it all goes through the current choke-points of the core
(people, guix-devel, etc), then they will get overwhelmed, or at least
will limit what could otherwise be achieved with more appropriate
tools/processes.

random example: the readability of plain-text emails pouring into
guix-patches, compared to e.g. threaded, formatted, and
displayed-in-context comment threads in a tool like gitlab.

i subscribed to guix-patches for a while, but it felt like noise.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Birds born in a cage think flying is an illness.”
	— Alejandro Jodorowsky