From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cHWoEhQHJGUUsQAA9RJhRA:P1 (envelope-from ) for ; Mon, 09 Oct 2023 15:58:44 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id cHWoEhQHJGUUsQAA9RJhRA (envelope-from ) for ; Mon, 09 Oct 2023 15:58:44 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E855A47C5D for ; Mon, 9 Oct 2023 15:58:43 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fq00WJYs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1696859924; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=K7hIHVjxUZX6CTsIKDFzaOiOCSEyzgQxTWzGxT6NTg4=; b=KE31gShLFfGAtVTUYx0WbU4lgaTQIZiJgBk+1EDHmEbWdxZ1Arlp/AjqscWF6XpJWPK3Ve w0sBnu8pReWl5GhmbmBYwZ3HITJKyMFCmsjKEz4tKMIgJ+IxPMxewFRjXONOy5ndAqieJ0 tdwSC/5Zeo8/EduRL7YyUZ8sXOz5ryWahCusViS2tkatOcaBkLCcjUQgrQ6erLkkwqrHK+ cWxZHTURWTZVIYSSK7qoGVENG7MnwxoBaCBqUdeFULoKD1ael96Cqk5l2jDvXAwNjGCnNI 9XsEzrmhyNY7o10MLZlPOdJYsGUV00T56nOO4mTRtIx29w662m/3o4Tga4Bgpw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fq00WJYs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1696859924; a=rsa-sha256; cv=none; b=YCpaVDeKTGXoWNGU76Eac6Xv9QyCcI1CrNbncxSZgCq4WLFKFYsY8REZ+YQfb3QEikcTiY io0OJwxxvCYTZf/pLs65E+Zb4GOkS91PzGei2U5XU2YIPrzajQA5nICawAK+lsl+7RGD4l rkWX38nzvl+dH4QQVxhlsPw+y/+keaFg1RzIGh6erPgDh9juh84bnilhKuPfiT4f/jspXH P5X6j2CspH5bSXndAlWDPmN4beQspWJsemYkbuXM9MVcKvd5RLB+VSkUKxtiMwaXa7jVZt o3L92lyjsczxvSw3umEzypVsCuW0nV4shbgxq5ZI4/cRYPIzJaDonJ96leiP1w== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qpqlu-0004UC-GD; Mon, 09 Oct 2023 09:58:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qpqbh-0007Bk-Cy for guix-devel@gnu.org; Mon, 09 Oct 2023 09:47:37 -0400 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qpqbe-00023l-J3 for guix-devel@gnu.org; Mon, 09 Oct 2023 09:47:37 -0400 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-9b6559cbd74so834672666b.1 for ; Mon, 09 Oct 2023 06:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696859251; x=1697464051; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K7hIHVjxUZX6CTsIKDFzaOiOCSEyzgQxTWzGxT6NTg4=; b=fq00WJYsvUWtSRGsqIegv6f7CdV7ybnhfrZp3Uv2g6dFrs4/DplLA8ZeElB9cUsecf FPVsazzj+f8ku2aJ4RRKlq352pAGK3TK9syOXHtgs7aDOF7m7xnOc0Mix/d7/Lk172Xu AeC+7CCfnTtqCgYIu9llhxKK1mGIrG8JGrphC5zVMMMZZo4HbItetJPh+hfw8AEX8xDl ztyCqrNfhFmxRpmZW97mU70+SLgoonn9DZRrZgydEVHUYD90XuggBvkOwEETT2df42VY /DWS2T9XL7gEvgUcQznaSgwOMHI4ajDj0eWZy49YsfQxtnnzyEMfbIExa6EXuJvD41cl QWaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696859251; x=1697464051; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K7hIHVjxUZX6CTsIKDFzaOiOCSEyzgQxTWzGxT6NTg4=; b=H5XFwYpx9PyY7eQWzWipVFAVBeG27XXB5Pbf3mc+cu7s16WgZ19vTEwm7ye5U9MMTr zi5HTQ3cteUlOOYPB/boJSloLbQI+zOhHXoV5tUcz5PjIgMHlZFYaKtgx5P/zwyIXLs7 9edBLmuaVeqTpLFr1BDsBFnzuiw+mpek+CbdSrb9i+UU22eY+9xEmrfyBNAH9MbYxf7G 0p054KAQUAGxweMLsz50TeeNOxY5EqO7nEwcpyWJ89m79mxK/AweGrWHJPYZtT7XrGCx YDkgyDW1TUNEpzYU2NG9Xfd/xtPZiOrdLh7Iw5uf7WbCSnU7OoLg3l+C76c6yMYzqWtz YmQQ== X-Gm-Message-State: AOJu0Yz1pCeWW0zI9PZtY/OhhBUIUBG1f0VCO8r83Gp3HGzGSoW+EKip LqvhhDcIqRjihGwGxoSLvw7/Aw79D+VvMjvAayA= X-Google-Smtp-Source: AGHT+IGFpVJySXTQcL1PZLNMC7GSHXAHjp92kbS3lHz1nqeRfM51SqaNTLv/du41m2kHyMNr5G51n/lEOo1nwM8Fa8I= X-Received: by 2002:a17:906:209a:b0:9ae:69b8:322b with SMTP id 26-20020a170906209a00b009ae69b8322bmr12802296ejq.60.1696859250928; Mon, 09 Oct 2023 06:47:30 -0700 (PDT) MIME-Version: 1.0 References: <87y1h6qjxl.fsf@wmeyer.eu> <875y3h1fnm.fsf@riseup.net> In-Reply-To: <875y3h1fnm.fsf@riseup.net> From: Lucy Coleclough Date: Mon, 9 Oct 2023 14:47:19 +0100 Message-ID: Subject: Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?") To: Tao Hansen Cc: guix-devel@gnu.org Content-Type: multipart/alternative; boundary="000000000000e2b369060748d4d1" Received-SPF: pass client-ip=2a00:1450:4864:20::631; envelope-from=coleclough.lucy@gmail.com; helo=mail-ej1-x631.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 09 Oct 2023 09:58:05 -0400 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.50 X-Spam-Score: -6.50 X-Migadu-Queue-Id: E855A47C5D X-Migadu-Scanner: mx2.migadu.com X-TUID: TaC1OHMU6qKS --000000000000e2b369060748d4d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To counter this point: > But the present organisation looks defunct. There=E2=80=99s no strong lea= dership. A lack of central-ised leadership is a good thing If this is their only reason for calling the organisation defunct then this point is invalid however I am unsure if this is where the critique lies In that spirit i am pondering how something akin to central leadership mandating such a change occur in this environment. The biggest concern I can think of about doing something like this and degrading existing workflows would be alienating developers who prefer the existing methods and perhaps had a hand in making them what they are currently. A lot of people in a company would likely grumble about such a mandate as a way of getting over it. I guess here some examples: - consensus could be tried for in a formal polling process and it be worked on post consensus - one could also do the work and propose it then to dispell any concerns of achievability but at the risk of it not being used - one could also try building an approach in which the project would gradually fade into a state where both options are viable, and then perhaps, should consensus be reached then, the project could fade into a state with solely the changed tooling example stages: - current tooling - git repo-s mirrored, chat channel-s bridged - facilitate project interaction on new git hosting method ( issues, mr-s, ...) - fade towards solely using the consensus desired tooling I think consensus is more suitable to large decisions than voting when maintenance of the group boundary ( guix devs) and maintenance of the number of states ( a set of tooling with only one tool per use case ( savannah or gitlab, matrix or irc, ...)) is desired an issue like this could cause a split and sometimes that is ok but when that is undesirable, if the one resulting state is formed then a continuous discussion process to form this one state into something which has the least cummulative "friction" is desirable. whilst this may be slower initially than a top down mandate, those adapting to a top down mandate would have to adjust from what they are most comfortable causing slow down in the future page 154 of this document presents a diagramatic representaion of a consensus process: https://www.radicalroutes.org.uk/wp-content/uploads/woocommerce_uploads/202= 2/10/How2WorkersCo-op2019A5Lo-Res-pslouz.pdf In defence of meta discussion, i think meta discussion is really just discussion where an assumed component is brought back into discussion. I am new to the project as well, in my experience I have found the mailing lists to be quite fun, i havent submitted any patches to guix yet so i can not comment on that perhaps an alternative could be mailing list propaganda to garner the excitement that currently surrounds something like discord one trend i have seen with guix is the tendency to use existing technology with extensions to achieve ones means instead of using/ developing a technology which includes all desired features as standard, maybe this is a function of the older style the irc and mailing lists are both publically logged and the system-s seem cohesive the logs on irc are harder to read than scrolling up in something like matrix, also the lack of non-text media can be tricky On Mon, 9 Oct 2023 at 11:29, Tao Hansen wrote: > > Hello, I hope it's ok I'm replying to this email as a follow-up to > decreasing the cognitive overhead for new users. I'm also brand new to > the Guix community and ecosystem. I wanted to share a perspective from a > user on a Lemmy instance who wrote why the Guix ecosystem was not > friendly enough to meet them where they were, a person in their early > twenties. I'd like to suggest approach their criticism with compassion > and open-mindedness. > > @velox_vulnus writes at https://lemmy.ml/comment/4625080 > > > I don=E2=80=99t like the vibe of ageism against young people that is > > associated with GNU. What is also frustrating is their reluctance to > > improve their infrastructure. > > > This reason is kind of terrible, I admit, but they could choose to > > move over to Matrix over IRC, but they choose to be willingly open to > > spam over having a proper, documented chat channel. I am also > > reluctant to use my personal mail, for the mailing list. Matrix gives > > me that anonymity, without also having to geopardize on participation. > > NixOS is on Matrix, and that=E2=80=99s why I like it. I know Matrix isn= =E2=80=99t > > perfect, but it the better choice between any other messenger. > > This user could use an email address dedicated to Guix discussion but > really I can only agree that sticking to IRC, which requires a lot of > effort to keep a history log and more effort to host a bouncer makes > contributing to synchronous discussions difficult. I, myself, am only > active on the community-run Matrix server and another, less free, > channel because the overhead is just too high. > > > They could choose to remove non-Libre JS from GitLab, Sourcehut or > > Gitea, or at least come with a new source hosting platform, but they > > choose not to. > > I also have a hard time with the insistence on the "Old Ways" as somehow > more pure, more legitimate than the new. There's some sense of the > expression, "You kids get off my lawn!" And the decentralized nature of > sending Git patches by email, which I still have not ventured to try, > makes it hard to *discover* Guix development in a single place. A user > needs to go to any one of the mailing lists, pull the Git repo or browse > Savannah or the issue frontend for bugs and new features they might be > interested in, and generally have an idea of what they want to be > looking for to find it. Discovery by serendipity is missing. > > When using the mailing list, even figuring out how to reply to the right > thread here in Gnus is trying and I'm not even sure if I've done it > right: people change the subject line, threads grow so large they become > unmanageable; I had to make sure I CC'd the whole list instead of just > reply to this mail's author. I still haven't figured out how to stick > guix-devel in my Gnus home screen: my starting view is always empty > and I have to remember the shortcut to get to the gigantic overview of > every Gmane list (this isn't a cry for help). > > There's more to their post: I encourage folks to check it out. > > We have the FOSS technology to tackle a lot of these critiques and bring > in a whole new wave of contributors. We have fully open Git forges and > modern messaging protocols to make a brand new developer-friendly Guix a > reality. > > --000000000000e2b369060748d4d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To counter this point:
> But the present= organisation looks defunct. There=E2=80=99s no strong leadership.
A lack of central-ised leadership is a good thing
If this is th= eir only reason for calling the organisation defunct then this point is inv= alid however I am unsure if this is where the critique lies
<= br>
In that spirit i am pondering how something akin to central l= eadership mandating such a change occur in this environment.
= The biggest concern I can think of about doing something like this and degr= ading existing workflows would be alienating developers who prefer the exis= ting methods and perhaps had a hand in making them what they are currently.=
A lot of people in a company would likely grumble about such a m= andate as a way of getting over it.
I guess here some examples:
- consensus could be tried for in a formal polling process and it = be worked on post consensus
- one could also do the work and = propose it then to dispell any concerns of achievability but at the risk of= it not being used
- one could also try building an approach in w= hich the project would gradually fade into a state where both options are v= iable, and then perhaps, should consensus be reached then, the project coul= d fade into a state with solely the changed tooling
=C2=A0=C2=A0= =C2=A0 example stages:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - current tooling
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - g= it repo-s mirrored, chat channel-s bridged
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - facilitate project interaction on new git hosting m= ethod ( issues, mr-s, ...)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 - fade towards solely using the consensus desired tooling

I think consensus is more suitable to large decision= s than voting when maintenance of the group boundary ( guix devs) and maint= enance of the number of states ( a set of tooling with only one tool per us= e case ( savannah or gitlab, matrix or irc, ...)) is desired
= an issue like this could cause a split and sometimes that is ok
b= ut when that is undesirable, if the one resulting state is formed then a co= ntinuous discussion process to form this one state into something which has= the least cummulative "friction" is desirable.
whilst = this may be slower initially than a top down mandate, those adapting to a t= op down mandate would have to adjust from what they are most comfortable ca= using slow down in the future
page 154 of this document presents = a diagramatic representaion of a consensus process: https://www.radicalroutes.org.uk/wp-conte= nt/uploads/woocommerce_uploads/2022/10/How2WorkersCo-op2019A5Lo-Res-pslouz.= pdf

In defence of meta discussion, i think met= a discussion is really just discussion where an assumed component is brough= t back into discussion.

I am new to the project as= well, in my experience I have found the mailing lists to be quite fun, i h= avent submitted any patches to guix yet so i can not comment on that
<= div>perhaps an alternative could be mailing list propaganda to garner the e= xcitement that currently surrounds something like discord
one= trend i have seen with guix is the tendency to use existing technology wit= h extensions to achieve ones means instead of using/ developing a technolog= y which includes all desired features as standard, maybe this is a function= of the older style
the irc and mailing lists are both publically= logged and the system-s seem cohesive
the logs on irc are harder= to read than scrolling up in something like matrix, also the lack of non-t= ext media can be tricky

On Mon, 9 Oct 2023 at 11:29, Tao Hansen &l= t;worldofgeese@riseup.net>= ; wrote:

Hello, I hope it's ok I'm replying to this email as a follow-up to<= br> decreasing the cognitive overhead for new users. I'm also brand new to<= br> the Guix community and ecosystem. I wanted to share a perspective from a user on a Lemmy instance who wrote why the Guix ecosystem was not
friendly enough to meet them where they were, a person in their early
twenties. I'd like to suggest approach their criticism with compassion<= br> and open-mindedness.

@velox_vulnus writes at https://lemmy.ml/comment/4625080

> I don=E2=80=99t like the vibe of ageism against young people that is > associated with GNU. What is also frustrating is their reluctance to > improve their infrastructure.

> This reason is kind of terrible, I admit, but they could choose to
> move over to Matrix over IRC, but they choose to be willingly open to<= br> > spam over having a proper, documented chat channel. I am also
> reluctant to use my personal mail, for the mailing list. Matrix gives<= br> > me that anonymity, without also having to geopardize on participation.=
> NixOS is on Matrix, and that=E2=80=99s why I like it. I know Matrix is= n=E2=80=99t
> perfect, but it the better choice between any other messenger.

This user could use an email address dedicated to Guix discussion but
really I can only agree that sticking to IRC, which requires a lot of
effort to keep a history log and more effort to host a bouncer makes
contributing to synchronous discussions difficult. I, myself, am only
active on the community-run Matrix server and another, less free,
channel because the overhead is just too high.

> They could choose to remove non-Libre JS from GitLab, Sourcehut or
> Gitea, or at least come with a new source hosting platform, but they > choose not to.

I also have a hard time with the insistence on the "Old Ways" as = somehow
more pure, more legitimate than the new. There's some sense of the
expression, "You kids get off my lawn!" And the decentralized nat= ure of
sending Git patches by email, which I still have not ventured to try,
makes it hard to *discover* Guix development in a single place. A user
needs to go to any one of the mailing lists, pull the Git repo or browse Savannah or the issue frontend for bugs and new features they might be
interested in, and generally have an idea of what they want to be
looking for to find it. Discovery by serendipity is missing.

When using the mailing list, even figuring out how to reply to the right thread here in Gnus is trying and I'm not even sure if I've done it=
right: people change the subject line, threads grow so large they become unmanageable; I had to make sure I CC'd the whole list instead of just<= br> reply to this mail's author. I still haven't figured out how to sti= ck
guix-devel in my Gnus home screen: my starting view is always empty
and I have to remember the shortcut to get to the gigantic overview of
every Gmane list (this isn't a cry for help).

There's more to their post: I encourage folks to check it out.

We have the FOSS technology to tackle a lot of these critiques and bring in a whole new wave of contributors. We have fully open Git forges and
modern messaging protocols to make a brand new developer-friendly Guix a reality.

--000000000000e2b369060748d4d1--