It's unrealistic for people to throw drive-by PRs and expect them to be merged. I can't imagine many cases where a drive-by PR should be merged, maybe: * Legi

It's unrealistic for people to throw drive-by PRs and expect them to be merged. I can't imagine many cases where a drive-by PR should be merged, maybe: * Legitimate bug fix with clear explanation. * Non-breaking enhancement that maintainer agrees with (low likelihood of agreement) Any other use of PRs (e.g. breaking change), if acceptable at all, should be coordinated with the dev team before expecting it to be merged. As the article says "engage (politely) in a long discussion." I'm not convinced that a PR should be the starting point for that long discussion, but that's how the github workflow works. imho the bar should be set very high for this kind of PR. Another use of PRs is: here's an interim patch that I made, that I don't necessarily expect you to merge, but maybe someone else will find it useful for developing a mergable patch. I see that quite a bit, and I think it's useful. The Github workflow doesn't really model intents of the above scenarios, or varying policies of different projects. I think it contributes to the problem.