emmaviolet (u/emmaviolet)

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

ohyoutravel · 18 days ago

Thanks a lot for taking this seriously. I regularly contribute but am not a “maintainer” so can’t really turn off PRs or anything, nor do I think that’s the right thing in this case. But some signal to spot these accounts at a glance before I go through and try to repro their issue or spend time engaging would be cool. Or immediate signal on “new accounts” (on HN usernames are green for like 30 days), or “account age vs PR velocity” would be interesting to me. Old accounts with regular PRs or Issues are not a prob, but the new accounts that just spam low quality issues and PRs are maddening.

emmaviolet · 17 days ago

Yep, totally get this. We're going to try and provide some quick solves first for the most affected maintainers, and then go back and make sure we can also help with the kind of nuance you describe.

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

ryandrake · 18 days ago

As someone on the other side of the PR, the current situation makes things awkward for me, too. Occasionally, I'll make an actual fix to scratch some particular itch I have with the software, and I'm hesitant to even open a PR, because it's just going to 1. pile yet another PR onto the maintainer, and 2. might get dismissed out of hand because it's mistaken for AI slop or other low-effort spam that these attackers are doing. So, I usually just fork, make the change in my own repo, and leave it at that.

Disabling PRs or limiting PRs to "contributors" would be a signal to me that I should just keep doing that and not contribute back to the main repo.

emmaviolet · 18 days ago

Totally get this. One thing we'd love to do is help make contribution patterns (not just guidelines) more visible to contributors, to help you get a better read of what's expected. Would that help? If so, where would you expect it to sit in your existing contribution flow?

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

jbreckmckye · 18 days ago

I get a lot of unsolicited PRs on my projects that I don't actually want

Turning off PRs would be a good option for several of my repos

emmaviolet · 18 days ago

Great, we're on it

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

FeistySkink · 18 days ago

It would help if PRs from newly-created or private accounts could stand out. And perhaps PRs from accounts that spam multiple PRs with dozes or hundreds of commits, would have some kind of a warning that only people with write access to repos can see. In fact perhaps GitHub could throttle those accounts from creating that many PRs in the first place.

Another suggestion would be trying to figure out if a PR was vibe-coded and marking them as such. Same as image-based social media tries to do.

emmaviolet · 18 days ago

That makes a lot of sense, and we've been considering some of those options too so good to know we're on the right track there. On trying to figure out whether a PR was vibe-coded: in some cases it's obvious, but in many cases it's hard to figure that out without AI, and we're not sure we love a solution that requires maintainers to use AI to tackle AI. My hope is that if we can provide some non-AI tools first (disabling PRs, creating more visibility around new users, etc), we can then build better management and triage tools with AI second. We're working on an Issues triage agent now that we hope to bring over to PRs too.

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

ohyoutravel · 18 days ago

I contribute regularly to some major open source projects and it’s happening here too. So many issues that aren’t issues. Constant “fixing” of documentation that doesn’t need to be fixed. Bug reports that aren’t bugs, followed by a bad PR “fixing” the “bug.” Or YOLOing an LLM PR to change major behavior that users are relying on. And I click and the authors are always brand new, with only vibe coded or examples projects in their history, and have some truly awful LLM generated GitHub “about me” page complete with emojis and links to their GitHub “projects.”

My suspicion is somehow the perception became that if you’re brand new and land a PR in a major open source repo (even as simple as rewording a phrase in a doc that doesn’t need to be reworded), that would help them get a job (they’re always Open to Work on their GitHub about me page).

It’s so much noise that it’s hard to find the real issues.

emmaviolet · 18 days ago

GitHub PM here. From what we've seen, you're right about the motivation; I've also seen plenty of job ads where "significant contribution to open source" is something that's called out explicitly as a valid substitute for professional experience in the area. While that's always well-intentioned and creates many benefits for the OSS community, the flip side is that it can also lead to the kind of problems you're seeing. Many new users are also motivated by learning and community, and not familiar enough with the community expectations to know how to seek that differently.

We have tried a lot here in the past (good first issues, more community support for new users), but haven't found a perfect solution yet. Internally, we're looking at options for admins to disable PRs on repos, or limit PRs to collaborators only, for example. From your comment, it seems like part of the challenge you're experiencing as a user is around Issues specifically. We've also been looking at options to delete PRs and Issues individually and in bulk, which could help after the event. Would welcome any feedback on other paths we could take here.

emmaviolet commented on We will ban you and ridicule you in public if you waste our time on crap reports curl.se/.well-known/secur... · Posted by u/latexr

normie3000 · 18 days ago

I've seen this - it's tiring even at low volume. Goes something like:

Someone creates a garbage issue. Someone else asks to be assigned. Someone from the project may say "we don't assign issues" (this step has zero effect over later steps). Someone else submits a PR. Maybe someone else will submit another PR. Maintainers then agonise how they can close issues and PR(s) without being rude or discouraging to genuine efforts.

emmaviolet · 18 days ago

GitHub PM here working on how we can make this problem feel better for maintainers. Really appreciate how tiring this can be, especially when even low volume is sustained for many months.

Would love your thoughts on some of the things we're thinking about: - Would it help to disable all PRs? All non-contributor PRs? - Would a "close as admin" button help address the issue of not wanting to be rude or discouraging? - What about Copilot doing an initial review and proposing to close anything that doesn't meet contribution guidelines - would that help a "close this" decision feel less personal?