[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About SWH, let avoid the wrong discussion
From: |
Ricardo Wurmus |
Subject: |
Re: About SWH, let avoid the wrong discussion |
Date: |
Mon, 24 Jun 2024 11:13:35 +0200 |
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.
- Re: About SWH, let avoid the wrong discussion, (continued)
- Re: About SWH, let avoid the wrong discussion, Felix Lechner, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, Luis Felipe, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, MSavoritias, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, Liliana Marie Prikler, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, Luis Felipe, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, Msavoritias, 2024/06/21
- Re: About SWH, let avoid the wrong discussion, Richard Sent, 2024/06/22
- Re: About SWH, let avoid the wrong discussion, MSavoritias, 2024/06/22
- Re: About SWH, let avoid the wrong discussion, Ricardo Wurmus, 2024/06/22
- Re: About SWH, let avoid the wrong discussion, MSavoritias, 2024/06/24
- Re: About SWH, let avoid the wrong discussion,
Ricardo Wurmus <=
Re: Next Steps For the Software Heritage Problem, Andy Tai, 2024/06/18
- Re: Next Steps For the Software Heritage Problem, Ian Eure, 2024/06/18
- Re: Next Steps For the Software Heritage Problem, raingloom, 2024/06/19
- Re: Next Steps For the Software Heritage Problem, Ludovic Courtès, 2024/06/27
- Re: Next Steps For the Software Heritage Problem, Ian Eure, 2024/06/27
- Re: Next Steps For the Software Heritage Problem, Felix Lechner, 2024/06/27
- Re: Next Steps For the Software Heritage Problem, Ludovic Courtès, 2024/06/27
Re: Next Steps For the Software Heritage Problem, Simon Tournier, 2024/06/19