- Mailing Lists
- Contributors
- Re: Reciprocity in PR opening vs reviews; banning contributors
Archives
- By thread 1472
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 57
- December 2025 33
- January 2026 63
- February 2026 48
Contributors
contributors@odoo-community.org
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
And an option less intrusive but maybe more effective as setting a priority on a rating of the contributor? Computed on reviews, porting, modules etc or whatever.Then show the PRs on this priority and set in the guidelines that they will be prioritized?Sergio CoratoIl ven 23 gen 2026, 21:41 Adam Heinz <notifications@odoo-community.org> ha scritto:I understand where this is coming from, but have trouble believing that punishment will yield additional reviews. A small number of my own pull requests have been fixes for modules that I don't even use, because they were breaking the repository build. Under the proposed system, I would have to spend additional time reviewing pull requests (that I don't care about) to earn the privilege of fixing modules (that I don't care about).Speaking outside of my own experience, 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.My best successes have been when another contributor and I accidentally worked on a fix or migration in parallel, then noticed each other and reviewed the better of the two prototypes. This suggests to me that perhaps a more granular ability to Watch a specific module instead of an entire repository could more easily put like-minded individuals in a position of mutual benefit (Jita Kyoei 自他共栄).On Fri, Jan 23, 2026 at 2:58 PM Holger Brunn <notifications@odoo-community.org> wrote: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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by joel.patrick - 02:15 - 25 Jan 2026
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