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

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Katherine,

On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

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

About the dismissive ad hominem response, sorry.  I should have clearly
mentioned that I was fully rejecting the rest but only keeping the
argument I was quoting.

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

Yeah.  I think I had already gotten it. ;-)

For someone who already plays guitar, then ukulele is “easy”.  For
someone who does not know any instrument or nothing about music, ukulele
is “hard”.  Although, the complexity of the ukulele is the same in both
cases.

« For which contributors do we want to/can we decrease the cognitive
overhead? », so I read it as: do we discuss about someone who is already
playing guitar or someone who is knowing nothing about music.

We already have the answer: we are speaking about someone who already
plays guitar (a skilled programmer).  As you said elsewhere in the
thread, we are all different, we all have different backgrounds,
etc. and the idea behind “easy is relative” implies that we have to
bound for whom it needs to be easy.

“How can we decrease the cognitive overhead for contributors?”  Here,
contributor is not explicitly defined.  In all the thread, the term
’contributor’ is interpreted very differently.  Well, I repeat my very
first message:

        Well, from my point of view, we are using here the term
        “contribution” as it was one homogeneous thing.
        
        [...]
        
        For example, a two-line patch trivially updating one package is
        not the same contribution as several-to-many two-line patches
        more some package additions for updating all the R ecosystem.
        And that’s not the same as rewriting the Python build system or
        as packaging the last version TensorFlow.

        The cognitive overhead for these 3 contributions is not the
        same.  Therefore, the way to reduce the friction will not be the
        same, IMHO.

A task is not “easy“ by itself.  It depends on 1. the complexity of the
task and 2. on the person who does it.

We are saying the same thing, no?

Now, this discussion has identified various frictions that are useless
and bring no value for the project.  It is clear that we need to improve
by smoothing or even maybe removing some of them.

Somehow, now we have to discuss about specific task, task by task, and
propose how to improve.  Survey is one next action for collecting data.

The other action for more automation is not clear yet.  We need to open
discussions about QA, scripts, etc.  For what my opinion is worth.


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

Saying it plainly and stretching a bit, yes “easy is relative” means
some people do not have the background to complete some process.

Reading the word “incompetent” as “not possessing the necessary ability,
skill, etc to do or carry out a task; incapable”

I am incompetent for playing guitar for example.  And playing music is
really not easy for me.  And so? :-)

It is related to the question: for whom it has to be easy.  A good
example is the switch to some web interface for the translation.  Some
translators does not have programming skills, so they are incompetent
for programming, and it was not easy for them to configure the tools for
contributing to translation.  The improvement had been the removal of
the friction by switching to some web interface.  Now, the process is
probably not easy for people like me that are not used to web interface,
although interacting with web interface is a simpler task than
configuring some tools for editing translation files.  Somehow, the new
web interface makes me “incompetent” for translating.  It is about
finding the right balance.  Hum, we are far from the initial
discussion. ;-)

Again, I think we are expressing the same thing and we are on the same
wavelength, I guess. :-)


> This is classic gatekeeping.

Sorry, I do not see any gatekeeping.  Because all seems open and many
people are doing their best for helping.  Maybe that does not work,
maybe that’s not enough, yeah maybe but I do not see “the practice of
controlling access to information, advanced levels of study, elite
sections of society, etc“.  Well, are you French? ;-) Because I feel we
are discussing unrelated points emerging although we are agree on the
core and we just detail tiny variations of the same thing. :-)


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

Are we on a wrong road?  Because we speak about the same thing, I guess:
a skilled programmer (you!) who wants to contribute to some packages and
does not find it “easy” by pointing several apparent frictions.  So it
means we have a problem!  Period. :-)

The question is how to improve?  Now, after discussing it – thank you
for opening this can of worms, it was necessary and this discussion is
very helpful!  – we have some items to act on, no?

Just to point, the root of the discussion about the commit message
format is about complexity, not about easiness.  Is the current format
too complex than no one finds it easy?

The various steps for checking and submitting patches are simple but
they are not easy.  Therefore, we must remove that because making hard
as not value.

About the commit message format, we could make it simpler, which would
lead to probably have something easier, but would we keep the value we
have with the current complexity?

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

Thank you very much for all the efforts and time you are putting in this
topic.  They are worth and very fruitful.  I totally agree with your
words:

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

And my point of view is that is a very big task so we need to start
somewhere and incrementally improve in order to reach this goal.

Cheers,
simon