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 3 hours ago | parent [-]

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 2 hours ago | parent | next [-]

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 2 hours ago | parent | prev [-]

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.

	▲	swiftcoder 19 minutes ago \| parent \| next [-]
		> 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
	▲	duskdozer an hour ago \| parent \| prev [-]
		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.