2 ms·

> 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

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

janosdebugs 3y ago
To me, what you are describing doesn't constitute a drive-by PR. You used the software, saw a bug, fixed it. This is the very best part of open source. (I hope the text in its entirety made that clear.) The kind of PRs I'm talking about are from people who have never and likely never will use the software, but want the badge of questionable honor of having contributed to a well-known project. The only reason they looked at the code is because they saw it in the news or someone told them to "go contribute to open source" to help their career. I don't mind a junior going to fix a but that they themselves found and know how they want the software to work. I do mind if someone goes randomly looking for something to contribute without understanding the software, how it's supposed to be used, and proceeds to expect maintainers to hand-hold them through the process of getting their contribution in so they can put it on their CV or satisfy a teachers assignment. I think what's rarely spoken about is the fact that each PR needs maintainer time. Maintainers are typically few and their time should be used to further the project, not for personal gain.
- mfuzzey 3y ago
  I think you and GP (about Lucas Chess) are using the term "drive-by PR" differently. I agree with the GP's definition. I consider a drive-by PR to be one made by someone who doesn't intend to become a regular contributor to the project but does have real motivation as a user of the project to get their "itch scratched" (a bug fixed or some feature that matters to them added). I also understand the type of PR you're describing (and agree with you that it's a bad idea) but I think it needs another term to describe it. Maybe "non user PR" or "CV driven PR" or "Vanity PR"? (edit sp)
- spacechild1 3y ago
  > To me, what you are describing doesn't constitute a drive-by PR. Drive-by PR simply means that the PR author is not a known community member resp. doesn't plan to become a regular contributor.
  - janosdebugs 3y ago
    My bad, I didn't know that that term was so established.

janosdebugs 3y ago

To me, what you are describing doesn't constitute a drive-by PR. You used the software, saw a bug, fixed it. This is the very best part of open source. (I hope the text in its entirety made that clear.) The kind of PRs I'm talking about are from people who have never and likely never will use the software, but want the badge of questionable honor of having contributed to a well-known project. The only reason they looked at the code is because they saw it in the news or someone told them to "go contribute to open source" to help their career. I don't mind a junior going to fix a but that they themselves found and know how they want the software to work. I do mind if someone goes randomly looking for something to contribute without understanding the software, how it's supposed to be used, and proceeds to expect maintainers to hand-hold them through the process of getting their contribution in so they can put it on their CV or satisfy a teachers assignment. I think what's rarely spoken about is the fact that each PR needs maintainer time. Maintainers are typically few and their time should be used to further the project, not for personal gain.

mfuzzey 3y ago
I think you and GP (about Lucas Chess) are using the term "drive-by PR" differently. I agree with the GP's definition. I consider a drive-by PR to be one made by someone who doesn't intend to become a regular contributor to the project but does have real motivation as a user of the project to get their "itch scratched" (a bug fixed or some feature that matters to them added). I also understand the type of PR you're describing (and agree with you that it's a bad idea) but I think it needs another term to describe it. Maybe "non user PR" or "CV driven PR" or "Vanity PR"? (edit sp)
spacechild1 3y ago
> To me, what you are describing doesn't constitute a drive-by PR. Drive-by PR simply means that the PR author is not a known community member resp. doesn't plan to become a regular contributor.
- janosdebugs 3y ago
  My bad, I didn't know that that term was so established.