On 30/9/26 23:48, Timothee Mathieu wrote:
Hello,
I am a Guix enthusiast, I use it for my personal setup as well as for
my research (in Machine Learning and Statistics) and I wanted to share
my experience on this discussion.
I tried (unsuccessfully) several times to contribute to Guix and every
time I fell short. Among these tentatives, I tried to contribute to
documentation a long time ago
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66295), and in the end
the ticket was closed prematurely. Remark that my suggestion from 3
years ago was in the end added to the documentation, not by me though.
I also tried several times to contribute on other subjects and
succeeded only once.
I think the current process is aimed at already established commiters
and beginners tend to be shut down quickly (at least this is my feeling).
A wiki would allow easier (although maybe less structured) contributions.
Maybe this is a feature, not a bug, as Ludovic was saying. But in my
opinion having a community more open to "easy" contributions (here for
documentation) would be beneficial. IMHO a solution to keep things in
sync with Guix can either be by having a small curated cookbook as it
is done now, or by having more people (i.e. people that are not yet
contributing to Guix) contribute and declare things "out of date" when
it becomes out of date. Remark that the lack of "how to" documentation
was already mentioned as one of Guix's bad side in the contributor
survey
https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/
On another note, I would also suggest that a wiki could encompass
other channels (I am thinking guix-science typically) and how to find
other channels, which is I think important. I already advised several
people, typically on reddit, on how to use external channels and how
to find them (via toys website).
So this was my testimony as a (very) enthusiast Guix casual user who
(several times now) failed to contribute.
Timothée
I've experienced this too and left for a few years. Actually I realised
a few years later my patch was included but they never closed the bug or
commented on it, so i missed it until I decided to search origin/master
one day. It's like the development process is a state machine that
exists between the brains of developers, and it can be difficult to
grasp what the future plan is or if there even is one, even after
reading hundreds of emails, issues, and pull-requests .
I've seen new contributors coming along to try help, not being able to
figure out what to do, and then disappearing . I'm currently working on
documenting my process for updating kde after someone asked how to do it
but gave up. I'm however simply not sure where to put it. should a add
sections to the contribution section of the documentation? id like to
document todo-list process of updating things, and use of tools like
diffoscope.
I'd like to tag Ricardo and to this and ask: Since you are taking a
break, can you reflect back at your process for updating R, look at your
shell history, and ask what knowledge you have that someone else trying
to update R themselves would have to need to know to learnt how to do it
from scratch, and then document it all, if it isn't already?
I'd like to develop a kind of Guix Contributor tool, that goes beyond
the contributing section of the manual, beyond the pull-request todo
list, and is more of a programmable todo list that walks someone through
defining their task and going through all the steps they should do,
ticking off completion. it would embed all the intuition and knowledge
of long time contributors that have gone through this loop in their
brains many times over.
