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

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

On 9/6/23 3:07 AM, Simon Tournier wrote:

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

This is an excellent analogy, and a very good parallel to the 
conversation about the Changelog format. It really made me stop and 
think! Thank you!

I can think of a rebuttal, but I'm going to drop this line of 
conversation, as you suggest, since it's not really the point.

> 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. )

Simon, for whatever it's worth, I think you're doing an amazing job. I 
think few people are able to simultaneously not understand something, 
but still engage in thoughtful and empathetic conversation. Really, well 
done.

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

That's interesting, because I view this as the antithesis of what Rich 
was trying to convey.

That quote is at the end of a dismissive ad hominem response which has 
grossly misinterpreted this discussion, even attributes it to malice, 
seems to draw the conclusion that contributing to Guix should be left to 
those for whom the current situation is fine, and even intimates that 
those who would like to improve the situation are incompetent.

Here's the quote from Rich's talk:

        The fact that we throw these things around sort of casually 
saying, "Oh I
        like to use that technology because it's simple. And when I say 
simple I
        mean easy. *And when I'm saying easy, I mean, because I already know
        something that looks very much like that*" is how this whole thing
        degrades, and we can never have objective discussion about the 
qualities
        that matter to us in our software.

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.

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.

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.

> 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.

This is crucial, so please forgive me if I belabor this point.

You are correct that there are a range of ways to contribute, and some 
of them are intrinsically more difficult. But irrespective of that range 
of difficulty, *improving the accessibility and experience helps everyone*.

This is a well studied phenomenon, but to highlight some of the common 
reasons:

- Ability waxes and wanes throughout our lives. Most often it is a temporary
   state of affairs. Everyone's ability declines in the end, and the 
work you do
   today to mitigate this will help you tomorrow.

- Solutions designed to help in a specific way often surprise us by 
helping in
   other ways.

- There is a negative feedback loop of not designing for X, which keeps 
people
   affected by X away, which gives the illusion that there's no people 
affected
   by X who are interested, which means we don't design for X. 
Proactively addressing this breaks that cycle.

In my original message I stated:

     I've written a script for myself that tries to perform all the steps
     including running the git command to submit the patch, and this has 
helped
     me, but that this is necessary for me to do might be something that, if
     addressed, could help others.

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.

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

> 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].

On the contrary, throughout this thread, I've thought that you 
understood the larger picture. I'm just responding to points where I 
thought I could contribute something, or where the points I've made have 
been challenged or questions have been asked.