1. Mailing Lists
  2. Contributors
  3. Re: Reciprocity in PR opening vs reviews; banning contributors

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Reciprocity in PR opening vs reviews; banning contributors

Re: Reciprocity in PR opening vs reviews; banning contributors

Avatar

Re: Reciprocity in PR opening vs reviews; banning contributors

by
Therp, Tom Blauwendraat
- 26/01/2026 22:26:15

For me it would be too much at once, and a bit of a blunt instrument.

It could also be hacked by someone giving out two blind LGTM reviews in the repo per each PR he/she wants to do.

What about an organisation-wide karma rating based on Enric's contribution statistics, perhaps adding more metrics there where needed, which the oca-git-bot then can read and apply labels to PR's that people then can choose to filter on? There are also some new tools out there that can detect AI contributions, so if someone does a lot of those, that could also negatively impact the karma score. When going below a certain karma rate, it then could lead to auto closing or banning, but that's something we could rather phase in gently.

-Tom

On 1/26/26 6:12 PM, Holger Brunn wrote:
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

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference