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

[Simon Tournier]

Hi Katherine,

    ( I feel we are not able to communicate on commit message format and
it seems we are on a road that leads to unfruitful output.  Well, I
appreciate the discussion and I have carefully read the messages. )


On Tue, 05 Sep 2023 at 20:34, Katherine Cox-Buday <cox.katherine.e@gmail.com> 
wrote:

> For whatever else has been brought up in this thread, I started with this:
>
>      I have given a list of issues to a group of people who are presumably
>      analytical, and I think the natural inclination is to go 
> point-by-point and
>      make arguments for/against. Instead of that[*], I invite you to 
> address the
>      more abstract issue: (should/how do) we reduce friction for making
>      contributions?

I agree with this, even if maybe I am misread.

For me, the reduction of the friction for making contributions means the
identification of such friction.  Once the friction area are identified,
it leads to an estimation about the order of magnitude of such friction
compared to all the other frictions.

As you said, we are all different, thus it means that any collaboration
cannot be full-frictionless.  Because any social interaction implies
norms and standards.  Norms and standards are by their definition
excluding.

For example, we communicate in English.  It appears to me impossible to
send a contribution without having some basic knowledge of English.  How
do I know that the English I wrote in the docstring, or in the comments
of code, or the name of the procedures, or in the commit message, etc.
how do I know that English is meeting the standard?  There is an
expectation about the English we are using for communicating and that
expectation is complicated enough that it’s easy to get it wrong.  What
is the thing that will tell me that the English I wrote is not meeting
the standard?

Why do we accept this “friction” about English filtering people?

Well, I am stretching a bit to make my point. :-)

I am trying to say that not all frictions are equal.  We collectively
must do our best to the reach equity, sure.  That’s said, we are hackers
and so we are improving what we are considering the most annoying.  You
find that running many commands for contributing is annoying so you are
trying to fix it.  I find some behaviour of “guix time-machine” annoying
so I am trying to fix it.  Etc.  The path for improving starts by making
apparent to all the annoyance, then optionally propose something – best
if one hopes the annoyance will be fixed :-) – and last the annoyance is
reduced for all when some proposal convinces folks.

My points are:

 1. thanks to all people for sharing their feedback
 2. the discussion is pointing many ideas that are actionable
 3. the discussion is also pointing friction that does not appear to me
    being actionable


> In the US, the phrase "I don't buy it" is usually the response to 
> someone trying to trick you into something. This is a little hurtful 
> because it's either saying:

Sorry, it was not my intent.  I was expressing: I do not believe it is
*the* real problem.


>> Well, I share various points that had been raised in this thread about
>> smoothing the contribution requirements.  However, I am still puzzled by
>> the comments about the commit message format.  Again, my inability to
>> understand the issue does not mean I am not hearing.
>
> Communication is so hard. My only advice is to remain aware that 
> everyone in the world is different, and that even when we don't 
> understand something, or don't experience it ourselves, that doesn't 
> make it less real, especially if there's a plurality of people agreeing 
> with one another. And to always choose kindness.

I hope that I am demonstrating to always choose kindness.

Well, if we do not have a common understanding about something, then we
cannot communicate about this something, IMHO.  Sharing a common
understanding about something is a core principle to establish
communication and collaboration.

If group A says ’foo’ and group B does not understand ’foo’, this ’foo’
is real for group A but is it real for group B?  Group A and group B
needs to have a common understanding about ’foo’ in order to agree on
how to deal with ’foo’.

My messages in this thread show, I hope, that I am taking seriously this
discussion.  I am doing my best to be empathetic and I am considering
all the concerns.  However, raising a concern does not make it real or
automatically equal with all the others.

    ( Do not take me wrong, I am not saying that for example commit
message format could not be a real friction for some people, I am sure
it is; as using in English is a real friction for some people.  Instead,
I am saying that I fail to get why is it or what makes this commit
message format a real problem. )


> Here is a great talk by Rich Hickey called "Simple Made Easy". Although 
> I recommend watching the entire thing, I'd like to draw your attention 
> to a few points:

Thanks for this pointer, I already knew it.  Yeah, that’s a good talk.
Maybe my first reply was a kind of unconscious digest of this. ;-) Well,
I have just watched it again. :-)

> - Easy is relative: https://youtu.be/SxdOUGdseq4?t=497

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?”

which is another way, IMHO, to express what I have tried to say with
“range of contributions” in my first message [2].

> - Differentiating the types of complexity (importantly defining 
> incidental complexity): https://youtu.be/SxdOUGdseq4?t=1173

It appears to me that it is also what I have tried to say in my very
first message [2]. :-)

        Well, from my point of view, we are using here the term “contribution”
        as it was one homogeneous thing.  Instead, I think the term refers to a
        range with a gradual complexity.  And the improvements or tools maybe
        also need to be gradual depending on this range.

> The crucial point of this talk for me is when Rich draws an analogy to 
> juggling (https://youtu.be/SxdOUGdseq4?t=1353). He poses the question: 
> you can juggle a finite number of balls; how many of those do you want 
> to be incidental complexity balls vs. problem complexity balls. In the 
> Guix world, how many of our balls do we want to be the meta of 
> contributing vs. actual code checked into Guix?

So yeah, I am definitely on that page. :-) I am sorry if you have not
felt that I am aligned since my very first message [2].


Well, now re-reading my first message, I feel I am repeating myself so I
move to other topics.

Thank you for opening the discussion and I am convinced that this
fruitful discussion will have a positive output reducing the current
friction for contributing.

Cheers,
simon

1: Re: How can we decrease the cognitive overhead for contributors?
Liliana Marie Prikler <liliana.prikler@gmail.com>
Tue, 05 Sep 2023 22:43:04 +0200
id:3b274703acaf446ec678e96c9d875c5d6b1a3e17.camel@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
3b274703acaf446ec678e96c9d875c5d6b1a3e17.camel@gmail.com">https://yhetil.org/guix/3b274703acaf446ec678e96c9d875c5d6b1a3e17.camel@gmail.com

2: Re: How can we decrease the cognitive overhead for contributors?
Simon Tournier <zimon.toutoune@gmail.com>
Thu, 24 Aug 2023 20:53:14 +0200
id:871qfsuvad.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/871qfsuvad.fsf@gmail.com