3 ms·
> I rarely even send PRs these days because those often rot for months or years As an OSS developer myself, something I'm not keen on is getting PRs out of the
by GordonS 6y ago
> I rarely even send PRs these days because those often rot for months or years
As an OSS developer myself, something I'm not keen on is getting PRs out of the blue - if it's something I don't want, or an approach I don't like, it's just really, really awkward.
I don't know if this is how you already approach PRs, but IME a good approach is to first open an issue outlining the problem/feature and how you intend to approach it. This starts a discussion with the maintainers, and may or may not later lead to a PR from you, depending on whether your plans fit in with the maintainer's.
- freedomben 6y agoThanks, I wholeheartedly agree. It sucks to get a PR that was clearly work that you want to reject because it's a direction you didn't want to go, has big flaws, or would be hard to maintain. I'm mostly talking about simple PRs, little bug fixes, even documentation improvements. But even big PRs, all I ask is basic human courtesy that we provide each other in meat space. It's totally fine to say, "Thanks but I'm sorry we won't accept this." especially when it's out of the blue. What isn't fine is being rude. It's wrecking the community.
- hombre_fatal 6y agoAlso, reviewing the PR and doing the people management along with it is a lot of work. And more work than doing it yourself. It’s certainly not free labor that costs maintainers nothing like people suggest in these comments. It’s more like having to work with a coworker who was employed for a couple days in difficulty and credentializing in what they left behind.
- freedomben 6y agoTotally agree. I think a "I'm sorry I don't have the bandwidth to look at this right now, but thank you for your contribution" would be perfectly fine IMHO. It's polite and decent, but still respects the maintainer.