* 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.
I really hope we can lower the barrier to entry without sacrificing code
quality precisely because of this. Lots of important use cases that
Guix could serve are ignored because the people who need them are not
represented in our community and/or they can't contribute and no one is
able/willing to write code for them.
* 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.
In a sense I agree with this, but if mistakes are this easy to make,
then I think something is wrong with the project, not with the
contributor. Instead of making people learn tightrope walking, maybe we
should be building actual bridges.
Guix actually fares pretty well in this regard compared to some other
projects I tried contributing to (*stares at Plan 9*), but there is
still a lot of knowledge that experienced developers take for granted
and don't actually document. Writing new packages is mostly documented
well, but as soon as something breaks, you are thrown into the deep end,
having to dissect logs, bisect commit ranges, learn strace, gdb (which
still doesn't work well on Guix), learn how to compile packages with
debug info (and actually waste some more CPU time and IO on rebuilding a
package you already have), learn how to adapt docs from other distros,
etc, etc, etc.
I've been trying to document these at least for myself, but haven't yet
had time to put them together into something others could read.
By the way, that's another issue. Using a TeX based document format for
the docs is, uuuh, maybe not the best idea. Info is a pretty okayish
documentation reader, but it's a relatively big barrier to entry
compared to what you need to know to make a small edit to the Arch wiki.
This way mostly just experienced contributors write docs, not the
users who just want to document how they made some weird use case
possible.