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

[MSavoritias]

On 9/10/23 01:20, Liliana Marie Prikler wrote:
> Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:
> > Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> >
> > > > Must we force a single workflow on everyone, even if our track
> > > > record in reviewing and merging doesn’t clearly show that our way
> > > > is superior?
> > > Again, define superior.
> > No, I won’t.  I think it’s obvious that our review process isn’t
> > working *well*.  So the argument that our current workflow allows for
> > effective review is dubious.  Not saying that you made that claim,
> > just that it’s hard to convince others of adopting our ways when the
> > results just aren’t great.
> What do you consider "the results" here?  The rate at which patches are
> merged?  This is hardly an issue our project alone is fighting and I'm
> not convinced that technology, more or less, will shift it in either
> direction.

That's one thing yeah.

There are multiple people in the thread pointing out issues with 
contributing that create friction.

Including an committer. And the fact that guix doesn't get have many 
committers and contributors are scarce, speaks for itself. If you don't 
see it I suggest asking people in social networks/forums why they 
*don't* get involved in guix.

> Let's take our importers as an example.  Bugs aside, they allow us to
> bump any package to the newest released version.  Naturally, similar
> tools have evolved over in the forge world as well.  The end result?
> Bots are now writing merge request that end up ignored much like there
> are bugs in Guix that receive little attention due to what might as
> well be unfortunate timing.
>
> I'm also not sure how we can tie back contribution throughput to
> cognitive overhead.  In fact, there might well be a Jevons paradox
> hiding somewhere in that less overhead per patch means that more
> patches can be written, which results in the same overall cognitive
> overhead in the long run.
>
> Now, you are probably right in that our review process probably isn't
> working well for some value of well that yet needs to be defined.
> However, without any frame of reference it is also a statement that can
> neither be verified nor falsified.  I could be sitting in a burning
> house claiming "this is fine" or sitting in the finest restaurant
> claiming "this place sucks" and since you can't see me, there's no way
> for you to infer that I'm a cat.
>
> Cheers
Frame of reference should be what other projects have done. Its not like 
this hasn't come up before in other projects.

For example Debian moved to Gitlab. Same for gnome and kde.

I'm not saying we should copy them but we should at least ask "Why?" and 
how did they come to those conclusions.

Then we should also do a survey of people outside of guix that may be 
interested in it. What stops you from doing so? (spoiler: its the email 
among other problems :) )


Personally free software means that there shouldn't even be a separation 
of Dev and user. But that's another topic.