unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lucy Coleclough <coleclough.lucy@gmail.com>
To: Tao Hansen <worldofgeese@riseup.net>
Cc: guix-devel@gnu.org
Subject: Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Date: Mon, 9 Oct 2023 14:47:19 +0100	[thread overview]
Message-ID: <CADVEqJ=jHiKgU9W7_CaU0RrB6qkdndseCARBYmiLBYCUhZX-Kg@mail.gmail.com> (raw)
In-Reply-To: <875y3h1fnm.fsf@riseup.net>

[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]

To counter this point:
> But the present organisation looks defunct. There’s no strong leadership.
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/2022/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 <worldofgeese@riseup.net> 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’t 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’s why I like it. I know Matrix isn’t
> > 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.
>
>

[-- Attachment #2: Type: text/html, Size: 7868 bytes --]

  reply	other threads:[~2023-10-09 13:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-16 12:59 Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?") Wilko Meyer
2023-09-17 17:55 ` MSavoritias
2023-09-18 12:02 ` Peter Pronai
2023-09-20  9:37 ` Simon Tournier
2023-09-20 21:51   ` Wilko Meyer
2023-09-21 17:23     ` Katherine Cox-Buday
2023-10-02 11:24       ` Wilko Meyer
2023-10-09 18:29         ` Katherine Cox-Buday
2023-10-12 14:43           ` Simon Tournier
2023-11-06 22:46           ` Wilko Meyer
2023-10-08 12:07 ` Tao Hansen
2023-10-09 13:47   ` Lucy Coleclough [this message]
2023-10-11  6:53   ` Kjartan Óli Águstsson

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='CADVEqJ=jHiKgU9W7_CaU0RrB6qkdndseCARBYmiLBYCUhZX-Kg@mail.gmail.com' \
    --to=coleclough.lucy@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=worldofgeese@riseup.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).