Sounds like a better way to make sure you have to be part of a clique to get your changed reviewed. I’ve been a long-time bug fixer in a few projects over the years without participating in IRC. I like the software and want it you work, but have no interest in conversing about it at that level, especially when I was conversing about software constantly at work.

I always provided well-documented PRs with a narrow scope and an obvious purpose.

Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it? Doing it alone should make it clear I don't need to ask to understand it. And why would I be interested in small talk? Doubt many people are when they patch up their work tools. It's a dispassionate kind of kindness.

Not to mention LLMs can be annoying, too. Demand this, and you'll only be inviting bots to pester devs on IRC.

Because you may misinterpret the correct fix or not know that your implementation doesn't fit the project's plans. Worse if it's LLM-generated.

> Why would I ask annoying questions when I can identify, reproduce, pinpoint the bug, locate it in code, and fix it?

Because if the bug is sufficiently simple that an outsider with zero context to fix, there's a non-zero chance that the maintainers know about it and have a reason why it hasn't been addressed yet

i.e. the bug fix may have backwards-compatibility implications for other users which you aren't aware of. Or the maintainers may be bandwidth-limited, and reviewing your PR is an additional drain on that bandwidth that takes away from fixing larger issues

If the maintainers are already bandwidth limited, how is first asking annoying questions not also a drain on that bandwidth?

The source and documentation is the context. And it's not like we don't have to deal with undocumented, uncommented, ancient patchwork code from time to time. I'd rather solve the puzzle than harass another volunteer who has a life if I can avoid it.

Also feel free to consider the PR itself to be the question, just with said context presented in one go instead of a back and forth. Feels more respectful, too. In the end, if it's not getting merged because of some weird hacky edge case, then my code will still live on in my fork.

“Why would I ever want to talk to other humans about things? Especially anyone who might have some kind of extra understanding on the project that I’m not currently privy to!”