MSavoritias <em...@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.
