[ryandrake]

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.

[normie3000]

> I'm hesitant to even open a PR, because...

For me the answer to this is to let go of all expectations. Fix things for your own purpose, and then open PRs to give the maintainers the option to engage or ignore.

Obviously from my post above, with my maintainer hat on I often fail to let go of the emotions. But it's a goal.

The lowest-stress PRs to handle are the ones with clearest test cases, and minimal incidental changes. Don't refactor, reformat or rename things to your own preferences and then expect a maintainer to engage.

Reducing changes to the meaningful minimum will also make your fork easier to maintain if the PR is refused, or ignored for months+ as the upstream project continues to evolve.

Ultimately, opening a PR is in part self-serving - best case is my change is upstreamed, worst case is I have taken time to streamline it, and simplify integration of future upstream changes into my fork.

[emmaviolet]

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]

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]

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!".

[moraesc]

A couple questions here - would more clear guidelines in the CONTRIBUTING.md file help in clarifying project direction and what contributions would be most valuable? Is there a better way for projects to indicate what issues should be prioritized? Do you ever want to run your contribution ideas past a maintainer before opening up a PR and if so do you ever do that? I'm curious if your itch may actually be something they're looking for too but it's not made clear in an effective way.

[boredtofears]

To be honest, I didn't really think about the goals of the projects at all. I'm not even sure if a CONTRIBUTING.md existed. I just needed a particular feature for something I was working and it felt like "being a good OSS citizen" to at least offer it back to the maintainer, but I think I just ended up putting them in a position where they felt like they had to make it work.