Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Reciprocity in PR opening vs reviews; banning contributors

Archives

Re: Reciprocity in PR opening vs reviews; banning contributors

Re: Reciprocity in PR opening vs reviews; banning contributors

Re: Reciprocity in PR opening vs reviews; banning contributors 

Thanks for your points.


> some of my colleagues who entered academia

> have lamented a similar sort of tendency in graduate students to favor the

> creation and publication of novel work for their theses, rather than review

> or reproduce the work of their peers

and wouldn't it have saved us several replication crises if you simply don't 
get to publish original work without attaching two replication papers?
What I want to do here is shift incentives. We have to recognize that many 
companies use publishing to OCA as a way of externalizing costs of QA and 
maintenance, and as free stamp of quality.
The individual employee then has the problem that they can use work time for 
publishing code, but not for reviewing. Tying those two together hopefully 
changes that.


> And an option less intrusive but maybe more effective as setting a priority

> on a rating of the contributor? 

I'd like that too, but we're constrained by the possibilities github offers, 
and that's simply not in the cards.
If too many see autoclosing as too much of a problem (obviously I don't, we 
really need to lessen cognitive load on maintainers), I could imagine a label 
"reviewing contributor" that is set on PRs of people who do enough reviews, 
and then other reviewers can focus on those PRs. But that won't be as powerful 
for the incentive shifting I talk about above.


> Can we give a way to appeal as well as a way to see what a

> PR reviewed line count is for the repo?

the action I've linked posts a message containing the line counts. Would be 
easy to add to the closing message too.
Appeal goes the same way as other cases like stale autoclosing: Ask 
maintainers to reopen/apply a label to exempt from autoclosing.

There is a class of janitorial PRs that should be exempted anyways, like fixing 
CI or updating from copier, but I wouldn't want to trust a stochastic parrot 
making that decision. And given those PRs tend to be merged fast, they don't 
strain your "line budget" for long. Note I propose to only count *open* PRs, 
once some PR is merged, it's off the ledger.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
by Holger Brunn - 06:10 - 26 Jan 2026

1 attachments 1 attachments

signature.asc

Reference

  • Reciprocity in PR opening vs reviews; banning contributors 
    Hi all,

on the OCA days, we discussed that the current situation with having way too 
much input for way too few reviewers is untenable. This has not improved 
since, quite the opposite. It's really hard to find the gems in the noise.

Back then, I called for better automation for this, so here my proposal:

Have a github action that counts lines of PRs somebody opened in a repo, vs 
the lines of PRs the person reviewed in that repo. Everyone must review at 
least twice as much as they submit.

If after asking for more reviews, no reviews come, close the user's PRs 
automatically (in the repo, not all OCA) after some time.

Also add a manual mechanism for banning users who try to cheat with bullshit 
reviews or otherwise undesirable behavior. PRs by banned users are closed 
automatically.

I implemented both in
https://github.com/hbrunn/social/blob/18.0/.github/workflows/reciprocity.yml
resp
https://github.com/hbrunn/social/blob/18.0/.github/workflows/ban.yml

You can test this by creating PRs against my fork after cloning my version of 
the 18.0 branch.
Banning works by adding a handle to a file .banned.txt in the repo's root.

Before proposing this to oca-addons-repo-template, I'd like to hear some input 
from you.

Best regards,
Holger


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
    by Holger Brunn - 08:56 - 23 Jan 2026

    1 attachments 1 attachments

    signature.asc