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

[Liliana Marie Prikler]

Am Montag, dem 18.09.2023 um 20:39 +0300 schrieb MSavoritias:
> 
> On 9/18/23 20:13, Simon Tournier wrote:
> > On Mon, 18 Sept 2023 at 18:35, MSavoritias <email@msavoritias.me>
> > wrote:
> > 
> > > I was talking from my experience. If you don't share it that is
> > > fine.
> > Share what?  Your experience?  How can I?  Instead, I share facts
> > backed by numbers.
> > 
> > It is fine to share how you perceive, encouraged even!  It is not
> > fine to make bold claim based on nothing more than a very
> > subjective view point.
> 
> Please take a step back. You cannot dismiss my experience.
> 
> As I have said and other people in this thread, and as I said i also 
> engage with people in social networks, and I am talking from that
> experience.
I think it is fair to say that experiences are subjective and
potentially misleading (and in the case of social media typically
subject to the bias induced by filter bubbles).  Now, the same
similarly applies to facts and statistics when given the wrong
interpretation, but first things first, we have to be aware of those
sources of bias and then work with them.  In this case it means not
making hasty claims on contributor count based on what you've heard in
social media.


Am Montag, dem 18.09.2023 um 11:37 +0200 schrieb Simon Tournier:
> Please point one project where:
> 
>   + more than 900 people have contributed to the project,
>   + more than 100 people had or have write access in the repository.
Some more data points captured by the same means you used, make of them
what you will:

Emacs: 1440/470
GCC: 2468/908
Nixpkgs: 7283/6339
Rust: 5657/5460
NPM (just the cli): 896/53
guixrus: 31/4

(As we can see, the pull request model hides how many people actually
have write access in some instances.)

What's not shown in these data points obviously are recent
contributions and active committers – we've had them posted at some
point, but that's old data by now.

Quite interestingly, Emacs and GCC both appear to have a 3:1 ratio of
contributors to committers despite using the same email-based workflow.
Perhaps that's due to age, or maybe it's a sign that we are too slow to
accept help? 

> The thing is nobody talked about email vs web forge to my knowledge
> though.
The thing is every discussion à la "maybe we should improve our
workflow somehow" eventually devolves into exactly this.  I have seen
my fair share of such discussions already in the short time I've spent
contributing to Guix.  The best that has so far come from it was people
spinning of their own channels (and even then, the use of another forge
appears almost incidental at times; our vetting process has similarly
been criticized for its perceived inefficiencies).

Now, I'd like to call back to a point I made earlier:

Am Dienstag, dem 05.09.2023 um 22:43 +0200 schrieb Liliana Marie
Prikler:
> 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?”
You can quite easily work around this issue by maintaining a
comparatively small channel for some thirty people.  However, you do
now have the cognitive overhead of being one of its four maintainers
while also trying to feed back whatever code has actually matured well
upstream to ease your own maintenance burden.  If that's the tradeoff
you want to make, then by all means, go for it.

> One of the solution offered was to have *also* a web interface. It
> was never suggested any comparison.
> 
> The comparison seemed to have stemmed from some people feeling they 
> would be left behind (?) and wanting to prove that email is better or
> something. Personally i don't care what is better.
I think you are underestimating the community splitting effects that
offering different *blessed* frontends has.  We are not talking about
your personal choice of a mail user agent here, because there's nothing
to bless; you simply take whatever is comfortable to you.  For blessed
web frontends OTOH, just offering two different representations of the
same data can already lead to problems, e.g. different bugs being
reported by the mumi vs. old school debbugs crowd.  This is also part
of the reason why large organizations tend to centralize their stuff in
one platform, which most forges make stupidly simple.  Even if they
could cater to different groups simultaneously, *they just don't care*.

Now Guix is already a little special in that it offers like three views
into this big pile of bug reports and patches (plus a fourth one if you
count yhetil).  If you're going to add yet another interface, you have
to consider maintenance (as Andreas pointed out early on) and possibly
different styles of etiquette encouraged by such interfaces (as I
pointed out soon after) or possibly other road bumps.  

Cheers