Re: Incentives for review

[zimoun]

On Tue, 19 Oct 2021 at 17:41, Ludovic Courtès <ludo@gnu.org> wrote:

> I would like to see us committers do more review work.  But I also view
> things from a different angle: everyone contributes in their own way,
> and each contribution is a gift.  We can insist on community
> expectations (reviewing other people’s work), but we should also welcome
> contributions as they come.

I am aligned with these words: «everyone contributes in their own way,
and each contribution is a gift».  I truly agree.

> There’s a balance to be found between no formal commitment on behalf of
> committers, and a strict and codified commitment similar to what is
> required for participation in the distros list¹.

I do not know (yet?) if I agree on that.  I would just say that many
more potential contributors are floating around.  We are already
selecting a small part of them using the email workflow (using another
workflow would select another part; who knows what is best ;-)).  Then,
the question is how to keep them?  Obviously, I do not have the
answer. :-) And sadly, I do not have number for backing an intuition.
>From my experience when digging into the bug tracker, I see many
submissions without an answer and people who seem to have given up.
Sadly, it is impossible to know why.

> A good middle ground may be to provide incentives for review.  How?  I’m
> not sure exactly, but first by making it clear that review is makes the
> project move forward and is invaluable.  You once proposed having
> ‘Reviewed-By’ tags to acknowledge non-committer reviews, and I think
> that would be one step in that direction.  Perhaps there are other
> things we could do?

Yeah, I think that non-committer doing review deserve rewards. :-) For
instance, the Linux project uses a lot of various tags [2].  The Guix
project could borrow some. ;-)

For instance, the Guix project uses Reported-by for bugs, somehow.  One
can imagine a Reviewed-by or Tested-by.

2: <https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html>

>>> I think it’s about finding the right balance to be reasonably efficient
>>> while not compromising on quality.
>>
>> I totally agree.  And I do not see nor understand where is the
>> inefficiency here when asking to go via guix-patches and wait two weeks
>> for adding a new package.
>
> It’s not about urgency but rather about not contributing to the growth
> of our patch backlog, which is a real problem.

Thus, why wait two weeks before pushing is an issue?


Cheers,
simon