unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Leo Le Bouter <lle-bout@zaclys.net>, guix-devel@gnu.org
Subject: Re: Leaving the GNU Guix community
Date: Fri, 30 Apr 2021 13:03:29 +0200	[thread overview]
Message-ID: <7950510e69564f59f7d9aa36a20cec5199285ded.camel@student.tugraz.at> (raw)
In-Reply-To: <888c71d21bbbc8dc7e8b4d5396694c83@zaclys.net>

Hello,

Am Freitag, den 30.04.2021, 01:43 +0200 schrieb Leo Le Bouter:
> I think that the GNU Guix maintainers justify unacceptable behavior 
1. What makes you think that?
2. How do you justify your own behaviour, specifically the kind of
behaviour, that others have asked you to justify?

> [The Guix maintainers] have acted upon things without understanding
> them, not understanding why incidents have happened
Where specifically?

> [M]any people have spread misinformation that other believed also.
What kind of misinformation was spread?

> I don't feel like there's any way forward to this, we really do not
> understand each other
Mutual understanding does not spring into existence from nowhere, it
requires effort.  You have always been quick to point out when you feel
misunderstood by others, but I don't feel you try to understand them in
turn.

> I don't know how to communicate the culture in some feminist/queer
> squats in France around Paris where I live, where we really feel
> together on the same page when it comes to these questions and where
> also we exclude people who don't understand these goals, in which I
> feel so good and where really every confrontation is avoided and has
> many values that building an inclusive community like GNU Guix wants
> to be.
I agree that avoiding conflict is a good heuristic when it comes to
being inclusive, but I don't think that purges are the way towards
inclusivity.

> I think that the technicality of software development must be
> redefined so that the hierarchy between the experienced and the
> beginner disappears, I think that to cast as a beginner or an
> experienced is an attitude, many people who are experienced cast
> themselves as beginners for various reasons and that some other
> people cast themselves as experienced for various other reasons. 
The notions of "beginner" and "experienced user" are already very weak
within Guix.  Of course, those who have a longer history of
contributing have accustomed to our rituals and thus feel less
alienated by them than someone who has to set up 'git send-email' for
the first time.  Such technical hurdles certainly exist, but I don't
think they bar anyone from contribution.  I feel the opposite is the
case.  Of all the software projects I've so far contributed to, Guix
was the easiest to get into.

> I think the difference between the beginner and the experienced is a
> construction, I think that such must be worked on so that every
> individual contributor can feel independent and empowered and also
> not have to define themselves towards the experienced. 
Guix already empowers its users long before they start contributing. 
As far as contributions are concerned I know of no process better than
peer review.

> I think that the technicality of software development implies a
> special kind of relationship with knowledge and experience, I think
> that also must be re-invented, and in other social environments like
> the feminist/queer squats I live in knowledge and experience is a
> really sensitive topic and people who have knowledge and experience
> are not always welcome to say what they know or what they think
> unsolicited and if they are solicited, there's also a way to say that
> to never imply a domination of student-professor, that to accept that
> someone does not want to hear about supposed knowledge and
> experience, and also needs and wants to feel proud and independent
> about what they are doing without the help of people with said
> knowledge or experience. 
I have no idea what to make of this blurb.  Are people really waving
around their commit log saying "I've contributed so and so many
packages, I am an expert™"?

> I think that in a sense, everyone must become a beginner. 
Everyone is a beginner.  Maybe not always, but also at no point never
again.

> I think it approaches a very fundemental topic of software
> development especially in Free Software communities that is to among
> others end meritocracy. I think that the world of Free Software and
> Open Source is tainted by that meritocratic spirit and that if we
> want to bootstrap inclusive communities we must embrace that
> underrepresented people also are of very varrying skill levels and
> that we must empower and include everyone no matter their skill
> level, and that this notion even of skill level disappears and that
> all people of varrying skill levels are also not interested in
> feeling submitted to a pre-existing group of people with knowledge or
> experience. 
I don't feel that Guix is tainted in the way you imply.  People
contribute according to their skill so as to satisfy their own and
other's needs.  When I say "contribute according to their skill", I
mean they use their (pre-existing or otherwise) knowledge of Scheme/the
Guix package API in particular to hack together mostly package
definitions, but also build systems, UI, the whole backend code, etc. 
And yes, that is certainly a skill to have.  You won't get package
descriptions from 1000 monkeys trying to write Shakespeare or an AI,
that renders pretty anime avatars. 

> That we must find other ways, tools, to organize tolerance for
> mistakes, collectively, that errors become not problematic at all, or
> that the possibility for error is removed, to create systems that
> detect errors and only accept non-errorneous input, so that as long
> as the contribution is a valid input from anyone, it is a valid
> contribution, that there's no room for doubting, for having failed
> to, for being responsible, for being accountable, for being blamed,
> if the tool fails to detect errors then we are collectively
> responsible for improving the tool, not individually responsible for
> triggering a validation bug. The tool also must be friendly with the
> way it rejects input, it must be helpful, it must provide guidance,
> it must not leave anyone no matter who they are, no matter what they
> know, in a situation where they have no idea what to do to create a
> valid contribution. I think that inclusive tools remove the
> possibility for error. I think that good UI/UX is when you can't go
> wrong, and that if you do, it's easy to undo what you just done,
> always. 
I'd rather subject myself to peer review than a benevolent machine
overlord, TYVM.  Yes, there are ways in which tooling can improve a
situation.  In the particular way you have recently erred, I think
'guix lint' would have raised some warnings.  However, I feel as though
making such tools mandatory effectively creates an entry barrier rather
than doing the opposite. 

> I think that GNU Guix is many situations many things can go wrong and
> I think that's not inclusive, it pushes off many people because it
> induces important amounts of stress to realize things can be wrong
> and especially when you can't undo them. 
There are plenty of opportunities and much time to undo an error. 
That's why we have a review process after all.

> I think that somehow the tolerance for mistakes or errors from anyone
> must be absolute, so that it is never an issue they happen. I think
> that for example with the design of the web where HTML parsers are
> tolerant to errors, that with JavaScript there's nothing that can
> possibly go wrong with code you write, ideally nothing can possibly
> be a security issue (not the case with JavaScript on the web but I
> think that if we were given a chance to give another go we could fix
> it), I think that such error-tolerant design is one of the reasons
> that there's also so many JavaScript developers of very diverse skill
> levels, that to me it feels very inclusive. I think that there's
> ideas to take from there. 
You're contradicting your earlier statement.  You can't have a system
that's both extremely pedantic and "fault tolerant" in the JS sense. 
Those are opposite extremes.

> I think also when we talk about practical software freedom, that we
> still have systems that can only be controlled by programmers, that
> the majority of people on earth are still bound to use tools they
> cannot control themselves. I think that to reach true practical
> software freedom everyone must be a "programmer", that controlling
> your system fully becomes so intuitive, so accessible, so inclusive
> also, because I think those topics are inevitably linked, that the
> need for "expert programmers" disappears. I think that software
> design is strongly entangled with the need for expertise and I think
> that for computing in general to become ethical as a whole the
> difference between a user and a developer, the words even, must
> disappear, become out of use, stop making sense.
There is a nugget of truth to be found in there, but I feel you're
drawing distinctions on unclear grounds.  Certainly a committer is a
developer and someone who only ever invokes "guix pull && guix upgrade
&& sudo guix system reconfigure /etc/config.scm" is not, but where do
people, who submit patches into your image?  I personally feel Guix
encourages more users to be developers (while that distinction still
exists) than any other system.

Also, you must consider the cognitive burden, that developing software
is, particularly for those who don't have a background in computer
science.  I am personally happy to teach anyone who is willing to
learn, but I acknowledge, that some people will only ever be interested
in getting their job done (using free software, of course), and that
first teaching them a programming language would be unsolicited advice.

Regards,
Leo



  parent reply	other threads:[~2021-04-30 12:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29 23:43 Leaving the GNU Guix community Leo Le Bouter
2021-04-30  0:31 ` Ryan Prior
2021-04-30  1:01 ` aviva
2021-04-30 11:03 ` Leo Prikler [this message]
2021-04-30 11:10 ` Ludovic Courtès
2021-04-30 17:54   ` Pierre Neidhardt
2021-05-01  2:34 ` Tobias Geerinckx-Rice
2021-05-01 14:45   ` Joshua Branson
2021-05-01 17:47   ` Léo Le Bouter
2021-05-05 14:27     ` raingloom
2021-05-01  4:51 ` Chris Marusich
2021-05-02  0:15 ` Making technology more inclusive Was: " Denis 'GNUtoo' Carikli
2021-05-05 21:11   ` raingloom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7950510e69564f59f7d9aa36a20cec5199285ded.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=guix-devel@gnu.org \
    --cc=lle-bout@zaclys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).