guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: MSavoritias
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Sun, 17 Sep 2023 19:20:48 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]