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

[Simon Tournier]

Hi Liliana,

On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler <liliana.prikler@gmail.com> 
wrote:

>> > > Must we force a single workflow on everyone, even if our track
>> > > record in reviewing and merging doesn’t clearly show that our way
>> > > is superior
>> >
>> > Again, define superior.
>> 
>> No, I won’t.  I think it’s obvious that our review process isn’t
>> working *well*.  So the argument that our current workflow allows for
>> effective review is dubious.  Not saying that you made that claim,
>> just that it’s hard to convince others of adopting our ways when the
>> results just aren’t great.
>
> What do you consider "the results" here?  The rate at which patches are
> merged?  This is hardly an issue our project alone is fighting and I'm
> not convinced that technology, more or less, will shift it in either
> direction.  

That’s not about “result” here.  That’s about “simple vs easy” or
“complex can be easy” or etc.

Similarly as submitting patches means that many steps are more or less
simple, then the complete process can be considered as relatively
complex.  To be explicit, I do not speak about being “easy” which is
subjective and instead I am speaking about some objective criteria
(e.g., the number of steps even if they are trivial).

Some part of that complexity has some value for the project and some
other part has no value.  The question is thus to identify and then
remove (or hide) the complexity that has no value for the project.

Today, the review and commit process have many steps, more or less
simple, not all sure!, well at the end, we have something complex.

One trivial step is to apply the patch (or series) to your local
checkout and so many things can lead to some useless frictions.  For
example, the patch does not apply because the base commit is not
provided, or because it is badly formatted, or because….  And one ends
to fix themself, e.g., probably using some manual trick just for
applying the patch.  No value for the project.

Yes, QA is currently helping for that specific example about applying
patches but the solution depends on why the patch does not apply.

Well, I am not saying that we should switch to PR model using
GitHub. :-) Let just recognize that our current workflow has many
drawbacks that make some frictions (steps with no value) for reviewing.
And PR model à la GitHub has many other drawbacks but at least it
reduces some frictions (technical steps with no value); mainly because
some people are paid for removing (or hide) these useless friction.

Don’t you agree that the review process implies many manual steps that
have no value for the project?

Last, I agree that the main issue when speaking about the reviewing
process is not about tooling.  The lack of a smooth technical solution
is just acting as a chemical developing solution in photography, it
increases the contrast and makes the poor image apparent.

Cheers,
simon