3 ms·

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 w

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.

devjam 4y ago
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.
veltas 4y ago
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.
samsquire 4y ago
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.
NohatCoder 4y ago
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?
- kop316 4y ago
  I think Linus has a good perspective on that. https://lkml.org/lkml/2004/12/20/255 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!
  - NohatCoder 4y ago
    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.
    - kop316 4y ago
      > 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)!
      - 4y ago
lanstin 4y ago
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.
- NohatCoder 4y ago
  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."
imtringued 4y ago
It makes sense if you are looking for new team members, the small patch is sort of an improvised interview.
- NohatCoder 4y ago
  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.

devjam 4y ago

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.

veltas 4y ago

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.

samsquire 4y ago

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.

NohatCoder 4y ago

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?

kop316 4y ago
I think Linus has a good perspective on that. https://lkml.org/lkml/2004/12/20/255 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!
- NohatCoder 4y ago
  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.
  - kop316 4y ago
    > 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)!
    - 4y ago

lanstin 4y ago

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.

NohatCoder 4y ago
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."

imtringued 4y ago

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

NohatCoder 4y ago
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.