3 ms·

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 tha

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.

nchmy 9mo ago
Everything about this is exactly what is happening in OWASP repos.
- Symbiote 9mo ago
  I pick the "block" option on the junk issue, and tick the "Send a user notification and show activity in timeline". The text says "A public timeline entry will show that this user was blocked" which I hope discourages them from wasting our time.
emmaviolet 9mo 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.
- zero_shift 9mo 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 9mo ago
    Great, we're on it
- FeistySkink 9mo 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 9mo 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.
- holowoodman 9mo ago
  Make it possible to turn off PRs from new accounts, accounts with a low PR acceptance rate or accounts that create lots of PRs all at once in unrelated projects. Or mark those kinds of PRs in a visible special way. Or make those kinds of issues and PRs non-public so that maintainers can silently drop them without creating publicity for the slop-spammers.

nchmy 9mo ago

Everything about this is exactly what is happening in OWASP repos.

Symbiote 9mo ago
I pick the "block" option on the junk issue, and tick the "Send a user notification and show activity in timeline". The text says "A public timeline entry will show that this user was blocked" which I hope discourages them from wasting our time.

emmaviolet 9mo 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.

zero_shift 9mo 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 9mo ago
  Great, we're on it
FeistySkink 9mo 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 9mo 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.
holowoodman 9mo ago
Make it possible to turn off PRs from new accounts, accounts with a low PR acceptance rate or accounts that create lots of PRs all at once in unrelated projects. Or mark those kinds of PRs in a visible special way. Or make those kinds of issues and PRs non-public so that maintainers can silently drop them without creating publicity for the slop-spammers.