Hacker News Reader

Comment by NohatCoder | Hacker News Reader

I really don't understand OSS maintainers that encourage or require people to fix or change things themselves. For a small patch the work of ensuring that the work of a new contributor is good enough is easily greater than just writing the patch yourself. And the time the contributor spent is likely much more.

Give me someone who does enough work that they get well acquainted with the code, or none at all.

View on HN

For anyone in doubt, I'm saying this as a maintainer, random people's patches on average suck. Taking those patches is likely to cost me more time than they save. So why would I be adamant about encouraging strangers to write patches?

I think Linus has a good perspective on that.

https://lkml.org/lkml/2004/12/20/255

Personally for me, the most exciting releases I have has for the OSS software I maintain are the ones where I was NOT the one who contributed the most code. Not only is my code used, folks thought of it enough that they wanted to help!

It is great if you can get the right people. But if you have someone who just needs one bugfix/feature so they can get on with their own thing, they are rarely the right people.

The person in this case clearly want to contribute, so spending time on them may be worth it in the long run.

> It is great if you can get the right people. But if you have someone who just needs one bugfix/feature so they can get on with their own thing, they are rarely the right people.

I think Linus' point is you never know. If you shot down MRs from other people, I am not at all surprised that you have not found the "right" people. I have found bugs in other projects with other projects. I will poke around at the source, and to see if I can fix it, but I also look at the MRs. If I see that sort of hostility towards MRs, I just don't bother.

On the other hand, with the projects I maintain, I have found that encouraging folks to submit their own MRs, even if it costs me more time to fix up their patches, more often than not, encourages them to help out more, test/report bugs with useful debugging more, and even contribute more (in either code or in the community)!

You may have had better luck than me.

It always turns out something like:

"Yes, please make that change, but don't do that refactoring/reordering/shuffling whitespace thing you suggested."

Change comes in, it is the actual wanted stuff, on top of refactoring/reordering/shuffling whitespace thing in the same PR.

I always try to be civil, but I can't deny that there is a possibility that some snark between the lines in my reaction may have scared them away.

Unless it's time-sensitive/critical, from the point of view of an OSS maintainer why should it matter whether a patch took 3 days to develop, or 3 minutes? As long as the quality and correctness is consistent across those patches, as a maintainer I'd encourage a wider base of developers who are fluent in my codebase, even if their initial PRs took slightly longer.

On most larger projects the 3 minute fix is more like 10-20 minutes depending on workflow, and they have many such issues in the backlog already. And most of the people who know your issue well enough to fix it that quickly are unpaid volunteers using their limited free time.

If you can ever actually encourage someone to fix something themselves, they just became a developer. They now have a non-zero chance of fixing other issues, or otherwise contributing. So it makes perfect sense to try and encourage people to contribute themselves, whenever possible.

What doesn't make sense is insisting when you could actually fix it yourself, you have time, motivation, etc, you just feel they don't deserve the fix.

The maintainer can implement your features faster than you can, but does that mean they should, or that it is fine for you to expect them to?

Nope, it isn't right. They are separate people from you and they decide what they work on, not you.

I wonder if that is language dependent. For C segfaults or Go panics, usually the obvious fix is the fix and at least the stack trace is extremely valuable that people wouls want, if not the author than any one wanting to fork and fix. Python usually people have more subjective opinions, at least in my experience.

Maybe a project in Java and web/JavaScript just tends to attract form over function people.

"We should migrate the whole project to use this framework." "The whitespace does not conform to this style guide." "I don't care if it breaks on old Androids, we should use all the new JS/HTML/CSS features, and I have already begun converting the code."

It makes sense if you are looking for new team members, the small patch is sort of an improvised interview.

Sure, but I'd much rather "interview" someone who is actually excited about contributing than someone to whom it was simply the only way of getting what they needed.

Reply on news.ycombinator.com