AI Slop Automation

[jmanico]

I propose we deploy automation that auto rejects AI slop. There are a few out there already that need to be evaluated.

The leadership team is rightfully frustrated and I want to find a solution to ease the burden of all the garbage we're getting.

[szh]

I'm in favor. Question is how accurate it is. What projects have you seen?

[jmanico]

flamehaven01/AI-SLOP-Detector – Static analyzer that flags fake documentation, inflated comments, and empty functions typical of AI slop. Useful for both code and doc files if documentation patterns are present.

... looks promising

[kwwall]

SMH regarding #1985 (comment). Oh the irony.

Perhaps we should also consider a ban list, at least a temporary one.

[jmanico]

I'm very much ok with a ban list for repeat abusers or first time obvious garbage.

[jdiegosierra]

Hi!

I wanted to share something I built that might be relevant: Contributor Report, a GitHub Action that evaluates PR authors based on objective metrics like merge rate history, account age, community reactions, and contribution patterns.

The goal is to give maintainers a signal about contribution quality without blocking legitimate newcomers.

This is my first open source project, so I'm genuinely looking for feedback :)

[jmanico]

I would love to experiment with this. This is a great idea.

[kwwall]

@jdiegosierra wrote:

I wanted to share something I built that might be relevant: Contributor Report, a GitHub Action that evaluates PR authors based on objective metrics like merge rate history, account age, community reactions, and contribution patterns.

On the surface, this seems an acceptable approach, but my concern is that it is focusing on the contributor rather than the contribution (i.e., the PR itself). That potentially could be a problem because even if it not the intent to judge a contributor, it could very well come across that way. Focusing on the contributor's history rather than the specific PR(s) under evaluation is not the proper focus. It could be skewed in that maybe the contributor does produce AI slop for a lot of PRs, but its where that FOSS community doesn't care as much because it's something that doesn't really matter all that much, like a small community of JavaScript developers creating various small JavaScript games like Tetris, mazes, crossword puzzles, Connect Four, etc. AI Slop might not matter very much where the participants are already apt to rely on Vibe Coding. But they may realize that the the OWASP Community wouldn't stand for AI slop and in essence, they would lose reputation points. Or the PR could be someone like @jmanico who would have a stellar score on something like this, but was having a bad day because they ran out of his favorite double espresso, so he just fired up his favorite genAI tool and tossed some PR over the wall (but definitely not over the @kwwall). So contributors that Contributor Report gives low scores to, could produce great PRs, but a really low score may bias us to just pass it off as AI slop without even looking at it. Or we could have a contributor with a stellar reputation have a bad day and use some AI shortcuts and then not diligently check the output resulting in AI slop. Now, I am not sawing that this wouldn't be useful because I suspect that most of the time there's going to be a correlation, so maybe it's a good first check.

The major shortfall of your workflow tool may be in assuming that "PR Merge Rate" is a useful metric. I think that depends on the assumptions. If 99% of the PRs were merged, I wouldn't put a lot of stock in that if 90% of those 99% were on the contributors personal repo and s/he did the vast majority of a bug fixes. (That is not actually that uncommon, even for larger projects.) So I think at least that one needs to be weighted somehow in value. The other important consideration here is how many PRs are needed before the calculations are meaningful. In my undergrad Mathematical Statistics class, my professor said from an experimental perspective, if you don't have at least 20 samples as a minimum, that any calculations that you make simply can't be statistically valid. So do we require at least 20 PRs? If so, that would probably eliminate half of the FOSS community because they are not regular contributors to FOSS projects.

The other thing is here to consider is that there are projects that just do feature branches and then commit directly to that feature branch and then at some point, merge the feature branch to their main branch or develop branch. But my point is, they never (or at least rarely) do PRs. So maybe we count commits instead of PRs or commits + PRs for that "PR Merge Rate".

Last question for now is for "Issue Engagement". What are you counting here? Someone creating issues? If so, where? Does it have to be in someone else's repo or can it be in one they own? What about just contributing comments as part of the issue discussion? How is that factored in and weighted vs issue creation?

Anyhow, bottom line, this does look interesting, so please don't take my comments as negative. For one thing it's late and I'm having troubles keeping my eyes open.

[jmanico]

Noted Kevin, but I still want it to easily identify first time or poor reputation submitters so my antennae are up more.

[jdiegosierra]

@kwwall Thank you for the feedback. I truly appreciate it.

While this tool may not cover every scenario, the goal is to provide maintainers with data points to help evaluate contributors. There may be instances of misjudgment, but I believe the metrics will be accurate in the majority of cases. The intention is not to discourage the use of AI in Open Source, but rather to rely on the responsibility of trusted contributors.

If an experienced contributor has a bad day and uses AI, they likely still understand the implications of their code. However, if they submit a poor quality PR, receiving negative reactions or having the PR closed will negatively impact their metrics. If they do this repeatedly, it is going to work against them. This system functions similarly to StackOverflow: you generally trust users with a high reputation, even though it does not guarantee they are always correct.

On the other hand, I plan to implement validations to prevent users from accumulating self-generated positive reactions. Reactions will only be counted if they occur in repositories that are not owned by the contributor.