Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Donnerstag, dem 07.09.2023 um 14:39 -0600 schrieb Katherine Cox-
Buday:
> > Somehow, that’s the remark by Liliana [1],
> > 
> >          Maybe it's time to take a step back and instead of asking 
> >          “How can we decrease the cognitive overhead for
> >          contributors?”, we should perhaps ask “For which 
> >          contributors do we want to/can we decrease the cognitive
> >          overhead?”
> 
> That quote is at the end of a dismissive ad hominem response which
> has grossly misinterpreted this discussion, even attributes it to
> malice [...]
Hi, pot, kettle speaking.  Now, I appreciate the ways in which you
think I might be misrepresenting your points even as I talk about the
points other people are making, but I'd appreciate even more if you
considered that you might also be (intentionally or otherwise)
misrepresenting the points others make.  You did so when Simon used an
idiomatic phrase for voicing disbelief, and you did it again here.

> seems to draw the conclusion that contributing to Guix should be left
> to those for whom the current situation is fine
This is the antithesis of what I am aiming for.  To quote my reply to
your initial message.

> Contributions are open to everybody (as long as they pass the first
> hurdle which is a very manual check to see if they spam our mailing
> lists or not), but the review process ensures that the outcome
> remains high quality.  This is desirable.
> 
> Now you might say that this leads to less diversity in the team of
> committers and maintainers as you need a certain level of privilege
> to seriously entertain the idea of dedicating that much time and
> effort to a project and I agree, but I also think this is a bigger
> reality of volunteer work in general.
TL;DR: Guix follows a model where contribution is open to everyone but
a select few decide which contributions make it upstream.  This is the
best we can get for the sole reason that we need quality control.  If
we didn't have the select few or the select few didn't do their job of
only accepting changes that don't "break the world" for all Guixers out
there properly, things would be very bad.

Now, Guix also has channels, which are fully free to all in that
everyone can run their own channel, but coming back to cognitive
overhead, maintaining your own channels *and* contributing to Guix
proper would at least in some instances be double work. 

> , and even intimates that those who would like to improve the
> situation are incompetent.
I assume you meant insinuates – maybe I don't do English like a native
speaker after all and intimates means the same – but again, I don't
think you're incompetent because you, say, fail to type a perfect
ChangeLog.  I would think it to be a little selfish if you submitted a
series of 100 patches and none of them had an even slightly useful
commit message, but that's only tangentially related to the point in
that I am so vocal about the ChangeLog thing because I already see
people not adhering to the convention and I'd really hate to encourage
the sending of such series.

Now, you say that you would "like to improve the situation", but I'd
like you to take a step back and first consider whether a given change
would actually end up "improving the situation" before committing to
it.  In the ChangeLog case, there is a lot to be gained from
automation, assuming the automation produces correct results and
doesn't hallucinate ChangeLogs à la ChatGPT.  On the other hand, there
is also much information to be lost if we were to switch formats to
something else, even if that something else is preferred by a group of
people that dislikes ChangeLogs.

> Contextualized, this quote is insinuating that I'm trying many
> different arguments in an attempt to push an agenda, and that because
> of this, any of the points I've made are suspect and should be
> dismissed.
If you're talking about the many different arguments thrown
specifically against ChangeLogs that I mentioned in the same message,
these actually came from different folks and I attributed them to no
one.  

> Read charitably, this quote suggests that there is a singular, best,
> way to do things, and that if it doesn't work for some, the problem
> is not the process, but that "those people" are incompetent.
> 
> This is classic gatekeeping.
Uhm, no it doesn't?  What I actually mean when I wrote these lines, is
that we all have (whether we are aware of it or not) a group of people
in mind that we care about when we say that we would like to improve
things.  Picturing this group clearly helps you when deciding your
priorities – which just like adjacency, is indeed subjective, and most
of the time we are thinking about an adjacent group.

For example, whenever people say that "forges would improve stuff", my
reply is (modulo phrasing) "yes, for the people who are already used to
forges".  Now, forges might indeed be familiar to many, but they would
also braid more things together.  You have to consider that when you're
thinking about the tradeoffs you're making.

> 
> Aside from the commit message, I've largely solved my problems. I'm 
> trying to advocate for others, and not just pull the ladder up behind
> me.
In the context of free software, sharing your ladders is typically a
good idea.  When you have a tool that helps you automate some task, you
should at least put that tool somewhere.  Even if we find that we can't
automate the process in the general case (because there's a case your
script doesn't consider), it will at least help some to see that you've
already thought about X, Y and Z.

> If Guix is for everyone, then we should do our best to ensure
> everyone can contribute with the things they're skilled at.
Sure.

Now, about easy vs. simple

> Rich is saying that there are intrinsic properties to approaches that
> make them simple, but possibly not easy, and that we shouldn't rest
> our arguments on claiming something is "easy", because that term is 
> relative, and often related to familiarity. Familiarity is a hard
> bias to overcome.
> 
> I'm here to discuss those intrinsic properties, the contributor 
> experience, and see where that leads us.
In my eyes, you have fallen victim to the easy vs. simple trap
yourself, but again, it's easy to fall into and as Rich pointed out in
fact a common misconception.  So, rather than discussing these terms,
please tell us what about the contributor experience is more complex
than it needs to be and where applicable, how you would like to
simplify it.  Bear in mind, that contributing already has at least one
degree of complexity baked right into itself on the basis of being a
feedback loop.

Cheers