[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incentives for review
From: |
Katherine Cox-Buday |
Subject: |
Re: Incentives for review |
Date: |
Thu, 21 Oct 2021 10:07:16 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Ludovic Courtès <ludo@gnu.org> writes:
>> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès <ludovic.courtes@inria.fr>
> But I also view things from a different angle: everyone contributes in their
> own way, and each contribution is a gift.
Maybe selfishly, but I really agree with this. I think this is just the nature
of community-based projects: people are going to scratch their own itch, and
when time allows, do altruistic things for other people.
Some people (e.g. me) don't have very much time at all to do the altruistic
things (which gnaws at me). I do what I can, when I can, and hope that someone
else benefits.
> 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.
>
>>> 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.
Often I find that people on projects/teams have fundamentally different
understandings of what reviews are for. Are they quality control? Mentoring
opportunities? Opportunities to teach others how something new works? A way to
encourage cohesiveness in the project?
It can help to publicly state the intent somewhere. I think the word "review"
is mentioned in the manual 11 times, but nowhere does it say what the review's
purpose is.
Large, public projects like Guix are a bit different, so I'm not sure this
applies, but reviews meant to be gates on quality are my least favorite:
(Please note: these are general observations about the industry and not
necessarily specific to Guix)
- The reviewers are human too, and there are various circumstances where they
will miss things. Some of the most insidious forms of this is are: tragedy
of the commons, i.e.
> Submitter: They always do such a good job catching things. I think this is
> good, but I know they'll catch any issues.
> Reviewer: I feel bad this has sat for so long, this person usually does a
> good job. +1 without a detailed review.
> Submitter: A +1! It must not have had any issues.
- Unavoidably, because of human nature, groups form, and certain people
experience less friction getting patches in. See the last point.
- There is a feedback loop present: those who have committed earlier have
control and are more likely to reject later commits which don't do things as
they would have. Sometimes "quality" is abused as a cover for opinion. Very
few people are doing this maliciously, but it still happens.
- As I mentioned in another thread[1], trying to chase the ideal of quality
may actually be worse in the end, or be a local maxima for quality or
utility. Focusing on velocity may help achieve the global maxima for both.
As always, there is a balance.
> It’s not about urgency but rather about not contributing to the growth
> of our patch backlog, which is a real problem.
I have often seen folks on various projects worried about the size of various
backlogs: bugs, issues, etc. I think it is human to want to try and contain
something that appears to be growing, unbounded.
I think the thing that bothers us is a sense that the backlog is becoming
unmanageable, or too large to triage. I submit that this is actually a tooling
and organizational issue, and not an intrinsic issue to be solved. Bugs may
still be valid; patches may still have valuable bones to modify.
I think the real issue is that as a backlog grows, the tools we're used to
using cannot answer the questions we want to ask: what is most relevant to me
or the project right now?
To me, this sounds like a search and display problem.
[1] - https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00081.html
--
Katherine
- Re: Incentives for review, (continued)
- Re: Incentives for review, Artem Chernyak, 2021/10/21
- Re: Incentives for review, Thiago Jung Bauermann, 2021/10/22
- Re: Incentives for review, Kyle Meyer, 2021/10/22
- Re: Incentives for review, Thiago Jung Bauermann, 2021/10/22
- Re: Incentives for review, zimoun, 2021/10/23
- public-inbox/elfeed -> Maildir bridge (was: Incentives for review), Kyle Meyer, 2021/10/23
- Re: public-inbox/elfeed -> Maildir bridge (was: Incentives for review), Jonathan McHugh, 2021/10/24
- Re: Incentives for review,
Katherine Cox-Buday <=
- Re: Incentives for review, Ricardo Wurmus, 2021/10/21
- Re: Incentives for review, Katherine Cox-Buday, 2021/10/21
- Re: Incentives for review, Arun Isaac, 2021/10/21
- Re: Incentives for review, Ludovic Courtès, 2021/10/21
- Re: Incentives for review, Ricardo Wurmus, 2021/10/21
- Re: Incentives for review, Arun Isaac, 2021/10/22
- Re: Incentives for review, zimoun, 2021/10/22
- Re: Incentives for review, Arun Isaac, 2021/10/23
- Re: Incentives for review, Jonathan McHugh, 2021/10/22
- Re: Incentives for review, zimoun, 2021/10/22