6 ms·

Isn't the obvious solution to not accept drive by changes?

ptnpzwqd 6mo ago
Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.
oytis 6mo ago
That's eliminating of an important part of open source culture.
- swiftcoder 6mo ago
  I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
  - oytis 6mo ago
    How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor. And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.
    - Muromec 6mo ago
      This sounds complicated in theory, but it's easier in practice. Potential long time contributor is somebody who was already asking annoying questions in the irc channel for a few months and helped with other stuff before shooting off th e PR. If the PR is the first time you hear from a person -- that's pretty drive-by ish.
      - DrewADesign 6mo ago
        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.
      - MadameMinty 6mo ago
        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.
        FridgeSeal 6mo ago
        “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!”
        duskdozer 6mo ago
        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.
        swiftcoder 6mo ago
        > 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
  - pmarreck 6mo ago
    how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?
    - swiftcoder 6mo ago
      Mostly by whether they check in first to see if the fix is actually welcome? Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
      - hunterpayne 6mo ago
        I've seen both ways. Sometimes the contributors let their ego prevent improvements to the architecture. Recently, I tried to get rid of a bug farm in a library I use. A single function was reduced to 1 line that depended on far more reliable method. And the maintainers put it back in later on (breaking my app yet again, sigh). In all fairness, those maintainers are academics who work for the French government so probably not the best representation of the community but still.
      - kpcyrd 6mo ago
        Your open source experience is very different from my open source experience.
  - CorrectHorseBat 6mo ago
    I can understand drive-by features can be a net burden, but what is wrong with a drive-by bugfix?
  - ckolkey 6mo ago
    I've gotta disagree with you here - it's not uncommon for me to be diving into a library I'm using at work, find a small issue or something that could be improved (measurably, not stylistically), and open a PR to fix it. No big rewrites or anything crazy, but it would definitely fit the definition of "drive by change" that _thus far_ has been welcomed.
    - duskdozer 6mo ago
      >find a small issue >No big rewrites or anything crazy I think those are the key points why they've been welcomed.
  - junon 6mo ago
    Hard disagree. Drive by's were the easiest to deal with, and the most welcome. Especially when the community tilted more to the side of non-amateurs and passionate people.
    - DrewADesign 6mo ago
      Low effort drive-bys were easy to spot because the amount of code was minimal, documentation was nonexistent, they didn’t use the idioms and existing code effectively, etc. Low-skill drive-bys were easy to spot because the structure was a mess, the docs explain language features while ignoring important structural information, and other newbie gaffes. One latent effect of LLMs in general is multiplying the damage of low-effort contributions. They not only swell the ranks of unknowingly under-qualified contributors, but dramatically increase the effort of filtering them out. And though I see people argue against this assertion all the time, they make more verbose code. Regardless of whether it’s the fault of the software or the people using it, at the end of the day, the effect is more code in front of people that have to revise code, nonetheless. Additionally, by design, it makes these things plausible looking enough to require significantly more investigation. Now, someone with little experience or little interest in the wellbeing of the code base can spit out 10 modules with hundreds of tests and thousands of words of documentation that all sorta look reasonable at first blush.
      - cindyllm 6mo ago
        [dead]
mcherm 6mo ago
I'm all in favor of not accepting "drive-by changes". But every contributor to the project had to make their first contribution at some point in time. What's the process for inviting in new contributors?

Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.

oytis 6mo ago

That's eliminating of an important part of open source culture.

swiftcoder 6mo ago
I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
- oytis 6mo ago
  How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor. And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.
  - Muromec 6mo ago
    This sounds complicated in theory, but it's easier in practice. Potential long time contributor is somebody who was already asking annoying questions in the irc channel for a few months and helped with other stuff before shooting off th e PR. If the PR is the first time you hear from a person -- that's pretty drive-by ish.
    - DrewADesign 6mo ago
      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.
    - MadameMinty 6mo ago
      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.
      - FridgeSeal 6mo ago
        “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!”
      - duskdozer 6mo ago
        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.
      - swiftcoder 6mo ago
        > 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
- pmarreck 6mo ago
  how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?
  - swiftcoder 6mo ago
    Mostly by whether they check in first to see if the fix is actually welcome? Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction
    - hunterpayne 6mo ago
      I've seen both ways. Sometimes the contributors let their ego prevent improvements to the architecture. Recently, I tried to get rid of a bug farm in a library I use. A single function was reduced to 1 line that depended on far more reliable method. And the maintainers put it back in later on (breaking my app yet again, sigh). In all fairness, those maintainers are academics who work for the French government so probably not the best representation of the community but still.
    - kpcyrd 6mo ago
      Your open source experience is very different from my open source experience.
- CorrectHorseBat 6mo ago
  I can understand drive-by features can be a net burden, but what is wrong with a drive-by bugfix?
- ckolkey 6mo ago
  I've gotta disagree with you here - it's not uncommon for me to be diving into a library I'm using at work, find a small issue or something that could be improved (measurably, not stylistically), and open a PR to fix it. No big rewrites or anything crazy, but it would definitely fit the definition of "drive by change" that _thus far_ has been welcomed.
  - duskdozer 6mo ago
    >find a small issue >No big rewrites or anything crazy I think those are the key points why they've been welcomed.
- junon 6mo ago
  Hard disagree. Drive by's were the easiest to deal with, and the most welcome. Especially when the community tilted more to the side of non-amateurs and passionate people.
  - DrewADesign 6mo ago
    Low effort drive-bys were easy to spot because the amount of code was minimal, documentation was nonexistent, they didn’t use the idioms and existing code effectively, etc. Low-skill drive-bys were easy to spot because the structure was a mess, the docs explain language features while ignoring important structural information, and other newbie gaffes. One latent effect of LLMs in general is multiplying the damage of low-effort contributions. They not only swell the ranks of unknowingly under-qualified contributors, but dramatically increase the effort of filtering them out. And though I see people argue against this assertion all the time, they make more verbose code. Regardless of whether it’s the fault of the software or the people using it, at the end of the day, the effect is more code in front of people that have to revise code, nonetheless. Additionally, by design, it makes these things plausible looking enough to require significantly more investigation. Now, someone with little experience or little interest in the wellbeing of the code base can spit out 10 modules with hundreds of tests and thousands of words of documentation that all sorta look reasonable at first blush.
    - cindyllm 6mo ago
      [dead]

mcherm 6mo ago

I'm all in favor of not accepting "drive-by changes". But every contributor to the project had to make their first contribution at some point in time. What's the process for inviting in new contributors?