all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: MSavoritias <email@msavoritias.me>
Cc: Richard Sent <richard@freakingpenguin.com>,
	 Andreas Enge <andreas@enge.fr>,
	 guix-devel@gnu.org
Subject: Re: About SWH, let avoid the wrong discussion
Date: Mon, 24 Jun 2024 11:13:35 +0200	[thread overview]
Message-ID: <87r0cmya80.fsf@elephly.net> (raw)
In-Reply-To: <20240624105556.7e92bc20@fannys.me> (MSavoritias's message of "Mon, 24 Jun 2024 10:55:56 +0300")

MSavoritias <email@msavoritias.me> writes:

>> > - Guix respects the consent of the person using guix lint and their expectations. (that lint actually lints)
>> > - Respects their privacy
>> > - Respects their autonomy.  
>> 
>> User autonomy is not curtailed by informing an aligned service's crawler
>> that an update has occurred.  You have a first class option to disable
>> whatever checks you don't want to run.  That's autonomy.
>
> It is in the sense that you haven't gotten the consent of the person
> running the linter on something that happens outside the context of
> "linting code".

But look: here you switch from "autonomy" to "consent".  You mentioned
"autonomy" before, and that's what I responded to.  Irrespective of
whether I agree with your assertion on consent here, I think it is
important not to conflate very different concepts when attempting to
build consensus in a community discussion (lopsided as it may be).  It's
how we end up talking past each other as one word points to another, and
we're led in circles.

It's also why I think it was a valuable contribution to the discussion
to draw a distinction between sending a URL and sending code.  It may
seem like nitpicking, but for me (in the role of the jaded observer
whose detachment is either the result of having attained enlightenment
or being uprooted by depression) it's a world of a difference: I'm okay
with a notification containing a public URL being sent, but I'd be
furious if my bytes were siphoned off.

While I have my nit-picking hat on, allow me to but-ackshually: "Linting
code" is not really what this is about, because we're dealing with
*packages*, not arbitrary *code*.  Within the context of Guix (which is
not, for example, a general purpose programming language where the unit
of interest is "code") I do think the assumption is a little too eagerly
impressed by prior experience with programming tools.  I'm not saying
it's somebody's *fault* for having an assumption like this, I just think
it's an unfortunate conflation of related but distinct concepts.

> Because from the places I asked in xmpp and here it seems everybody
> that is not reading the docs or knee deep in guix project, assumes it
> just lints and is surprised it does more things.

Yes, we've had similar problems in the past where documentation is not
considered and individual assumptions (developed by other the use of
other tools, because intuition is a lie) are used as the yard stick
against which the behavior of tools is judged.  Examples include "guix
refresh", "guix package", "guix container", "guix archive", and even
"guix repl".

"Nuance" is an emergent property; no single word can be nuanced, so in
my opinion a command name cannot possibly carry enough information to
accurately represent the gamut of its behaviors.  We can only hint at a
general direction and use the term as an index into documentation.  We
have several layers of documentation; the first pointer would be into
the output of "guix help".  Perhaps changing the short description shown
next to "guix lint" would reach those averse to documentation, to colour
the pointer in ways that better hint at the concepts it points to in the
manual?

> Seeing how this thread has devolved I am wondering what the next steps
> would be to address this. Seeing as diversity and a welcoming
> environment wasn't kept.
> Open to suggestions of course :)

I think it is very difficult to feel welcome when people don't
understand or disagree with you.  I've been there myself, countless
times before.  The very attempt to express myself clearly is intensely
uncomfortable; it's like walking on egg shells, but not because of a
community failing, but because any error in representing my view point
is going to make the waters more turbulent, confuse the issue, spawn
requests for clarification, or sub-threads on issues that really don't
matter to the originally intended point.

And yet, all the properties of a pleasant community are exemplified in
the process of untangling the knots of disagreement.  I think it is
dangerous to label the attempts to argue an opposing point of view and
the attempts to define boundaries as "arguments in bad faith".  This is
a sure fire way of sabotaging one's own goals.  We're all operating
under very limited information about other people's points of view,
their amount of information, their values and the amount of overlap with
our own.  For some of us, defining a topics boundaries is a precondition
to understanding details within them.

Passionate people often run the risk of steam rolling a budding
discussion. [And this is my cue to disconnect from it again.] The sheer
volume of messages can intimidate people and keep them from making their
voice heard.  (I, too, have been intimidated by this thread, even though
there is no reasonable threat to my standing in the community if/when I
make a fool of myself.)  I read that in Sociocracy meetings, people
speak up one after the other, in turns, and not again before everyone
else has been heard.  Here we don't even know who is in attendance, so
that's not easily modeled.  Also, email with its ever-branching
sub-threads easily devolves into the average emacs-devel "discussion".

Simon's proposed RFC process (which I support) aims to improve this by
putting a consent-seeking process first.  I think it would be a good
alternative to whatever this is :)  This topic would benefit from a
declaration of statements (which members of the community can refute or
agree with) and an actionable proposal.

-- 
Ricardo


PS: Unless specifically addressed, the above is not directed at any one
person in particular.  I'm only capable of seeing stories and themes,
but the actors and their actions are all a big blur to me.  Such is
looking out from this here brain, smoothened by age and defeat.


      reply	other threads:[~2024-06-24  9:14 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  8:37 Next Steps For the Software Heritage Problem MSavoritias
2024-06-18 14:19 ` Ian Eure
2024-06-19  8:36   ` Dale Mellor
2024-06-20 17:00     ` Andreas Enge
2024-06-20 18:42       ` Dale Mellor
2024-06-20 20:54         ` Andreas Enge
2024-06-20 20:59           ` Ekaitz Zarraga
2024-06-20 21:12             ` Andreas Enge
2024-06-21  8:41             ` Dale Mellor
2024-06-21  9:19               ` MSavoritias
2024-06-21 13:33                 ` Luis Felipe
2024-06-21 17:51               ` Exclude checker with package properties [draft PATCH] Simon Tournier
2024-06-21 18:37                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-21 18:44                   ` Simon Tournier
2024-06-21 18:42                 ` Simon Tournier
2024-06-22 15:54                 ` Draft: dry-run + Exclude checker with package properties Simon Tournier
2024-06-20 21:27         ` Next Steps For the Software Heritage Problem Simon Tournier
2024-06-18 16:21 ` Greg Hogan
2024-06-18 16:33   ` MSavoritias
2024-06-18 17:31     ` Greg Hogan
2024-06-18 17:57       ` Ian Eure
2024-06-19  7:01       ` MSavoritias
2024-06-19  9:57         ` Efraim Flashner
2024-06-20  2:56         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-20  5:18           ` MSavoritias
2024-06-19 10:10 ` Efraim Flashner
2024-06-21  8:39 ` About SWH, let avoid the wrong discussion Simon Tournier
2024-06-21  9:12   ` MSavoritias
2024-06-21  9:46     ` Andreas Enge
2024-06-21 10:44       ` MSavoritias
2024-06-21 13:45         ` Luis Felipe
2024-06-21 14:15           ` MSavoritias
2024-06-21 16:33             ` Luis Felipe
2024-06-21 17:04               ` Msavoritias
2024-06-21 16:34             ` Liliana Marie Prikler
2024-06-21 16:51         ` Vagrant Cascadian
2024-06-21 17:22           ` MSavoritias
2024-06-21 20:51             ` Vagrant Cascadian
2024-06-22 15:46               ` MSavoritias
2024-06-22 17:55                 ` Breath, let take a short break :-) Simon Tournier
2024-06-24  7:30                   ` MSavoritias
2024-06-24 10:23                     ` Tomas Volf
2024-06-24 11:56                     ` Lets cut this off Efraim Flashner
2024-06-21 17:25           ` About SWH, let avoid the wrong discussion Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-22 13:06         ` Richard Sent
2024-06-22 14:42           ` MSavoritias
2024-06-22 19:53             ` Ricardo Wurmus
2024-06-24  7:55               ` MSavoritias
2024-06-24  9:13                 ` Ricardo Wurmus [this message]

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

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

  git send-email \
    --in-reply-to=87r0cmya80.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=andreas@enge.fr \
    --cc=email@msavoritias.me \
    --cc=guix-devel@gnu.org \
    --cc=richard@freakingpenguin.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.