There's (at least) four Fs, and the first in the list should be "File it".
Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.
I think that's because maintainers consider tickets as action items for them personally instead of treating them as feedback documenting known issues(sometimes with workarounds) for their users. I think DeVault put it very well a while back: a ticket is the place where the community can gather and exchange feedback on a perceived issue with a project (I'm paraphrasing).
I find that I do this less than I would otherwise, because I'm not sure if it will be interpreted as a demand that they fix it immediately, either by the developer who may already be dealing with entitled users or just feel compelled to help users of their software, or by random passer bys who use open 'bugs' as a metric to attack people with.
It would be neat if you could contribute information on issues, suggested fixes, workarounds with some guarantee that it was in a format that would actually help the maintainer, rather than stress them out.
Usually I just end up spending a reasonable amount of time thanking them, explaining that what I've noticed isn't a big deal for me, just something I think they might want to be aware of etc. But some systems should be put in place for this, like being able to tag issues as "I see this bug too" but also seperately "this is important to me" so widespread, but low priority issues can be prioritised and information gathered.
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.
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?
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)!
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.
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."
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.
Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.