> This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again.

I have a fairly controversial take on drive-by PRs: They're great IFF the submitter is an experienced developer.

I did a drive-by PR on LucasChess.

I tried to use LC on a Linux desktop, and there were showstopper GUI bugs. I tried on a few different distros with the same result. I looked into the code and found that a few Qt values in the Python-GUI portion had "wrong" values (i.e. they were ignored on Windows, but were honored on Linux). I made a fix. I did a few tests. I submitted the PR with a message about the bug, how to reproduce and how exactly the patch will fix the problem, and went on with my life (the very definition of a drive-by PR). The project accepted the PR as is.

That's literally how projects get better: someone takes the time to diagnose a problem, make a fix, submit the fix and move on whether or not the fix is accepted. When enough people are doing this the project maintainer might be using all their project time only reviewing PRs, but at some point there's just too few bugs left in the product to take up much time on the maintainer's part.

The problem is when an inexperienced developer makes a PR. Odds are good that they didn't diagnose the root problem, didn't chase down the docs (for Qt, in this case) for explanations, didn't try to replicate on different systems, didn't document what the bug is, didn't explain in the PR how to reproduce the bug, didn't test the fixes and/or never used the product themselves (I still use LC almost daily).

"Experience" means "I know how to do all of the above, and have done so in the past".