3 ms·

Open source can be a wonderful thing when people come together and build something cool. Unfortunately, maintainer burnout has been a thing recently and part of

Open source can be a wonderful thing when people come together and build something cool. Unfortunately, maintainer burnout has been a thing recently and part of the reason is that IT and open source are seen as a way to get a lucrative job. Some (and by no means all) people disregard the consequences of their actions to get there. Juniors should absolutely be encouraged to either build a project on their own or collaboratively, or to start by joining the community and listening before starting to write code. 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. These drive-by PRs come in a variety of forms. Some are just absolute nonsense, some rename things for no good reason, some refactor a part of the code that nobody asked for, and some do add a tiny bit of value, but are extremely bad quality to the point where rewriting it would take less time than going through several (dozen) review rounds explaining to the budding contributor how to write code. (Or how to even use git. Rebasing a PR is a problem for a lot of people, for example.) Maintainers of open source projects typically didn't sign up for being mentors to people who barely know how to code. More than that, these random PRs increase the noise level in the project by a lot and take away time from the contributors, junior or not, who put in way more effort that a drive-by PR author did. Leaving PRs to rot is bad because they will start having conflicts, so not reviewing them is not an option. Each of these PRs needs to be properly reviewed because they have a maintenance cost later that rests on the shoulders of the maintainers, not the contributor. Each PR carries the risk of someone introducing malicious code. Answering these PRs politely but firmly also takes quite a bit of effort. Yes, juniors should be encouraged, but realistic expectations should be set. Contributing code to a highly complex project probably isn't going to happen. They should try and contribute to small projects that they themselves know and use. That way they understand what is good an what is bad for that piece of software. Also, they should "read the room" and the contribution guide before jumping in. The best way to start is with small things: reporting issues, fixing docs bugs, and once they are comfortable with the workflow, move up to writing code. Unfortunately, communication is hard and getting this message across ("be considerate") to the right people is harder. This post has a good analogy for that with the bricks.

lelanthran 2y ago
> 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 2y 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.

lelanthran 2y ago

> 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 2y 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.