contributing: limit open PRs for new contributors to 1#20036
contributing: limit open PRs for new contributors to 1#20036am17an merged 1 commit intoggml-org:masterfrom
Conversation
|
This should hopefully soon be a setting. |
|
At JabRef we handle this by limiting the number of good first issues new contributors can assign to themselves and github actions count their contributions: https://github.com/JabRef/jabref/blob/4cbe485f7f280f130326889566cb75bab1c359b2/.github/workflows/on-issue-comment.yml#L35 Limiting the assignments to a low number became necessary because we had malicious contributors competing for a GSoC project by assigning themselves to all good first issues in an attempt to prevent other aspiring GSoC participants from picking any, lol. |
|
seems fine to me, although it could be better to make a bot that manage this automatically the suggestion from @ThiloteE also seems to be a good one, which encourage new contributors to look at existing bugs instead of "just vibe-code" a new thing |
|
Thanks :-) I am not sure, if our approach that forces contributors to assign themselves and pushes them towards good first issues that are managed centrally by JabRef maintainers, scales to a repo with as many contributions as llama.cpp. Also, JabRef is currently not in a position where major downstream projects build upon it, hence we lack contributions that make their way up from downstream. I can imagine that if upstreaming PRs is artificially bottlenecked, downstream projects might consider independence at one point. Regardless, I wanted to share it for brainstorming. Maybe it is inspiring ;-) |
|
I support the goal but I'm not sure whether limiting open PRs would make a meaningful difference. Submitting machine-generated PRs is already against the rules, adding another rule will I think not fix the issue. Personally I have installed Auto Highlight to highlight EM dashes — the usage of those is a pretty clear sign that the text was not written by a human. |
The aforementioned upcoming setting will allow a hard enforcement as well as some heuristics, will hopefully prevent spamming without blocking legitimate use. |
IMO it feels quite tempting to make our own bot to just do a pre-review pass for new PRs though. The bot can be contain a set of heuristic checks, the goal is to remind contributors and maintainers about key points before diving into the code. One of the check that I can think of could be to detect AI's commonly used unicode (emoji, arrow, em-dash) and simply report if the PR contains such characters Another check could be like: if both CPU and device backend code are changed in the same PR, simply remind the contributor that it may against the guideline (just remind, but take no actions) If maintainers are interested in this idea, I can move it to a dedicated discussion. |
|
Can someone approve this? There are many PRs which can be closed using citing this policy |
|
@ngxson That was a yes on the bot BTW. |
To avoid to cases where a contributor is not aware about AI policies and creates PRs wholesale using their AI of choice