Hey y'all,
Ekaitz, thank you for opening this thread. RIP your inbox.
I think this thread demonstrates in itself one of our biggest issues. A
few folks have mentioned it indirectly. I'll be direct. We can't stay
on topic.
So once again, Ekaitz, thank you for clarifying what this discussion is
supposed to be about. In the context of consensus decision-making, this
is part of what's called facilitation, and it's absolutely vital if we
want to use a consensus decision-making model for governance. I think
we absolutely can do that if we just use the tools others have built
for making consensus work -- like the idea of facilitators.
But I digress.
After that preface, I'm going to respond specifically to the points
Ekaitz highlights as the topic of this thread.
> - Do we need independent funding so we can pay for our machines and
maintenance?
I don't know the details of cost and source off the top of my head
(they were recently summarized in another thread), but my instincts are
screaming, "Yes!" I'll return again to this later, but we should be
paying people to do systems administration work because systems
administration is boring and tiring after a while. Above all, no single
individual should have to carry the weight of paying for our servers.
> - Is the Guix Foundation the way to do it?
Again, I don't know enough to say with certainty, though most likely.
Because...
> - Does GNU, or the FSF, have some role on that?
...Guix should break with GNU and the FSF. Moreso the FSF, but the two
are irrevocably intertwined in the public conscious -- which is the
primary reason Guix needs to break away. To avoid relitigating what has
been litigated more than sufficiently already, the FSF made a bad
political move that has destroyed its social capital and, as a
side-effect, its financial capital as well. Even if it can help us with
funding, it shouldn't. (More on why in a bit.) In terms of extant
infrastructural support, from what I can tell, the FSF gives us hosting
for a simple website, an ancient git forge, and mailing lists. While I
can't speak to mailing lists, I can speak to websites and git forges.
Given the incredible complexity of our existing CI and QA
infrastructure, putting up some HTML and having a gitolite service
running on a machine are comparatively no effort. I suspect the mailing
list -- after migration -- would be the same, though I reiterate my
ignorance here.
To forestall misunderstanding, I absolutely do *not* mean that Guix
should compromise on free software. Guix's greatest strength is that it
is an uncompromisingly idealistic and principled project. If we change
anything about our stance on non-free software, it should be that we
add a single sentence to the manual informing people about the
well-known and well-supported channel providing non-free firmware,
followed immediately by a disclaimer that we neither endorse nor
support non-free software, and that's *all*. Official Guix channels
should never knowingly ship non-free software, nor should we ourselves
provide instructions on installing, configuring, or using non-free
software itself -- we should just point people to the place that does.
Why, though, should we go through the effort of migrating our mailing
lists, domains, etc. just because it won't add *that much* more work?
This is a big and important question. The short answer is, the FSF is
radioactive, and we're getting sick from it.
Let me be frank. I promote the heck out of Guix. I've shilled Guix to
more people than I can count, from professional systems administrators
at internationally-acclaimed universities to hobbiest hackers in the
most obscure corners of the internet, and everywhere in-between, all of
whom are incredibly capable, knowledgeable, passionate programmers, and
some dozens of whom are free software hackers. The main turn-off people
cite to me is our association with GNU. As a particularly poignant case
study, in conversations with someone who has contributed significantly
to Guix on my recommendation and did not stay around, the primary
complaint was not the email-based workflow (which was noted as unusual
but not overwhelming), but that the GNU affiliation *makes them feel
uncomfortable in our community*. They haven't told me of negative
interactions with members of the Guix community; the GNU affiliation
alone was enough. If we recognize that there is not enough growth in
effort going into the project, we should address the primary reason
we're not getting new people to bring more effort: GNU.
> - Can we improve anything relieving weight from the shoulders of some
people instead of putting even more on them?
I think so. As I noted above, if we break with GNU, I am highly
confident we will see an uptick in new contributors, at least some of
whom can help there. In the longer-term, we absolutely need to pay more
people to do systems administration for the Guix project. If we start
paying people, those are the people we should pay first. Our patch
throughput doesn't matter if we don't have servers to distribute those
patches to users.
> - Would having more committers help relieve some of the weight?
Perhaps? This could allow more experienced contributors to focus on
less-supported areas (sysadmin, for example) and help the overallow
distribution of labor as a result. The issue is less the number of
committers than the number of *commits* by relation to the patch
backlog. To that end, any changes related to committers should focus on
increasing patch throughput. In particular, we should focus on adding
contributors who want and are able to help with specifically patch
review. Indeed, my inability to commit (pun not intended) to patch
review is the only reason I haven't put myself forward for commit.
(Though I am working towards giving myself the time for patch review in
the near-ish future.)
> - If so, should we propose commit access to people, instead of
waiting them to propose themselves?
Yes, and, to reiterate, we should prioritize committers who want to
focus on patch review. This doesn't mean we *only* grant commit to
people who want to review patches, but there should be a clear
expectation of patch review for any new committers. Committers who see
someone consistently providing good patches and/or review should be
able to propose that person to the other committers.
> - Should we ease the process of becoming a committer?
No, with one exception. If the committers discuss among themselves and
feel that someone is making consistently helpful, quality contributions
to Guix, but they haven't contributed 50 patches yet, they should be
allowed to offer that person commit. For self nomination, nothing
should change. Guix should not compromise on its ideals. We need people
with a demonstrated dedication to those ideals screening others for the
same dedication before entrusting them with material power in the
project. Our current process seems well-suited for this end.
That's all I have to say at the moment.
As a final note, I want to highlight the amazing work from Arun Isaac
and Chris Baines. While I know y'all have been working hard on Guix for
a long time, I've paid the most attention to y'all's work this year,
and from what I've seen, y'all have been kicking ass. You've made it so
that the contributor workflow is not a meaningful point of weakness
anymore. Thank you both.
Best,
Juli
