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 5 hours ago | parent | next [-]

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?

▲

mnkv 2 hours ago | parent | next [-]

My ideal is copilot that would evaluate the PR against some basic guidelines that maintainers write down.

And perhaps a way to filter PRs to just contributor PRs would be easy to implement and pretty useful

▲

ryandrake 5 hours ago | parent | prev [-]

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 3 hours ago | parent | next [-]

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?

	▲	ryandrake an hour ago \| parent [-]
		I always thought it would be nice to see some kind of "maintainer profile" for each project, that the maintainers could set up: Is the project open to PRs? What is the quality bar for PRs? How much developer testing is expected before a PR is accepted? Are there any automated test coverage requirements/expectations? Sort of like a more structured version of CONTRIBUTING.md. Also, statistics about past PRs: How long does it take, on average, before the maintainer responds to a PR, before it gets merged? What % are rejected or closed? How many edits do PRs for this project on average need before being accepted? What is the current incoming rate for PRs and what is the current merge rate? I could look at these and figure out if a project can sustain yet another incoming PR or if they are in over their heads. And it would help me understand what level of "done" they are expecting. Maybe some of these are even already available--i haven't really explored GitHub that much. Hope this helps.

▲

boredtofears 4 hours ago | parent | prev [-]

Yeah, I kinda stopped involving myself in other people's OSS projects a while ago for that reason. If I have an itch to scratch, I just use my fork. It usually feels like my itch isn't theirs and I always feel like I'm imposing on the maintainer's vision or at best just taking time away from them. I think maintainers have a lot of pressure to accept things because "open source!".

▲

halapro 9 hours ago | parent | prev | next [-]

You've been getting PRs? All I've ever seen is "can you assign this issue you me" spam and then disappear. I was nice to them for years but now I just delete the comment and block the users.

	▲	nchmy 8 hours ago \| parent [-]
		Yeah, the "can you assign the issue to me" is the most common. I don't even understand where it came from - does anyone ever actually formally assign issues to anyone? But they absolutely also create PRs even if you say "don't create a PR. You don't know what you're talking about"

▲

nchmy 10 hours ago | parent | prev | next [-]

This is precisely what we've seen

▲

thephyber 10 hours ago | parent | prev [-]

Those maintainers should be using LLMs to crate their breakup letter with the Issue/PR submitters!