emmaviolet

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.

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?

Great, we're on it

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.

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.

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?