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

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

On 8/24/23 12:53 PM, Simon Tournier wrote:
> Hi,
> 
> At some point, I sympathize.
> 
> On Wed, 23 Aug 2023 at 10:25, Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:
> 
>>    I don't use the email-based patch workflow day-to-day, so this is
>> another area where I spend a lot of time trying to make sure I'm doing
>> things correctly.
> 
> I agree that Debbugs is not handy at all for submitting patches.  Send
> the cover letter, wait, refresh email, wait, refresh email, loop until
> an issue number is assigned, and then send the series.

Yes, and imagine that between every step, it is likely that something 
pulls your attention away. Maybe you have ADHD, maybe a kiddo is asking 
you endless (but interesting) questions.

This is where the overhead begins to erode contributions. People can end 
up spending their limited resources managing the workflow instead of 
improving Guix.

> Reduce friction for making contributions?  Yes, we all want that, I
> guess.  The question is how?  What is the right balance between the
> change of habits and the satisfaction of people used to these habits?

I think a good start is to eliminate toil for everyone. It doesn't 
matter how something is done if it doesn't need doing! Manually 
organizing/pruning imports is a good example.

The good news is that we are working with computers which, among other 
things, are purpose-built for automating away toil :)

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

That's a good point, but even along that gradient, there's a baseline of 
toil which is not a function of the complexity of the code.

But also, even for complicated things, a tight loop of exploration is 
useful for getting things right. For some, as I alluded to above, it's 
even a critical component for even completing the task.

>> * We could support a managed web-based workflow
> 
> Here, I am very doubtful that it would help.
> 
> For instance, Debian is based on Gitlab since their switch from Alioth
> to Salsa.  It would be interesting to know if this “new” web-based
> workflow using Merge Request is increasing the number of submissions
> and/or increasing the number of occasional contributors.

It's a good question.

> Another example is Software Heritage (SWH).  Their web-based workflow is
> a Gitlab instance [1].  As an occasional person who deal with the SWH
> archive, I am never able to find my way and I just roam on #swh-devel
> IRC channel asking for help.

I think there's utility in distinguishing between familiarity and 
eliminating toil. I think it was incorrect of me to suggest forming 
habits in my original message. I think it's better to focus on 
eliminating toil so that whatever workflow remains can more easily be 
habituated.

> Another example: the channel guix-science [2] based on GitHub.  Well, I
> am able to count using one of my hands the number of PRs. ;-) (And I do
> not speak about other channels as nonguix)
>   
> Well, reading the item above about mistake and the item below about
> "Guix 'R Us", and maybe I am wrong, somehow I feel that one “cognitive
> overhead” is the willing to submit a perfect patch.  Again, maybe I am
> wrong, somehow I feel that one part of the issue is a lack of
> self-confidence.  Do not take me wrong, I am speaking about submitting a
> patch by occasional contributor and not about the personality of person
> that I do not personally know. :-)
> 
> This “that’s not perfect so I postpone the submission” is something I
> often hear by people attending to Café Guix [3].  Hum, I do not know
> what we could do differently for reducing this barrier.
> 
> The idea of the team Mentor is in this direction but it does not seem
> working… :-(
> 
> 1: https://gitlab.softwareheritage.org/explore
> 2: https://github.com/guix-science/guix-science
> 3: https://hpc.guix.info/events/2022/caf%C3%A9-guix/

Similarly, I think there's utility in distinguishing between learning 
and cognitive overhead. I can learn anything, but there are factors 
beyond my control that cause high levels of cognitive overhead to cause 
enough friction to stop me.

Mentorship is a great thing, and I'm sure I"d learn a lot from a mentor, 
but it wouldn't solve the problem I've raised unless the mentor somehow 
showed me how to eliminate the cognitive overhead, in which case: let's 
just do that for everyone.

> For sure, I think that part of the solution is by finding the way to
> collaborate.  Somehow, what would be your expectations for contributing
> more?  Or for easing your contributions? :-)

A fast feedback loop with as few points of interruption between writing 
code and submitting a patch.

--
Katherine