Signaling bugs is as much work as it is to send a patch. Sometimes is even better work. For instance a bug report that is the fruit of a deep investigation is worth a lot more than a weak patch that is fixing the problem in the wrong way, often because of lack of understanding of the system. I don't agree there is a clear distinction of patches and bug reports in which one is work donated to the project and the other is not.
Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
> Signaling bugs is as much work as it is to send a patch.
No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable.
Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working.
And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself.
Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals.
In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer.
Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations.
If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable.
A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug.
All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
A quick fix is a great way to describe a bug for the person that understands the system.
On many projects the mantainers ask way to much of the submitter in following some guidelines. I feel they think they should not "steal" the submit from the submitter or something becouse fixing stuff for them would equal the work of commenting it.
Highly depends IMHO. A good bug report that doesn't just says "X happens sometimes" but figures out when and why, or provides in-depth reasoning for what the behavior should be, can be a lot more work than the code fix, or a new feature.
It might be a nice to have a place where people can file low-effort bug reports, or perhaps "symptom reports", where there's no expectation that a maintainer will respond or even look at them.
Then they could be treated rather like automated crash reports: you could mine them to see if a problem is common, or if someone reports a strange problem you might be able to see whether anyone else had seen it and look for common factors.
Seems hard to make it work in practice without it turning into a place where people would just rant. Maybe if you make the reports readable only by the project's maintainers?
It's a bit of an unusual idea, but I'd suggest that making symptom reports more public would help -- as long as they are anonymized and opt-in.
That's a really tricky technical problem to achieve, since many bug reports depend on the user's local environment in order to reproduce the problem, and that could conflict with anonymization.
Making problems public creates incentives for the project to fix issues (since they can't hide their existence) and also provides opportunities and information for contributors to help resolve them (including for purely selfish reasons, to fix issues that affect their own systems too).
I programmed quite a lot of C/C++/Java code in my life (looking back at it, close to 3 million lines), and I consider good, reproducible bug reports an important contribution. An app full of new features that the users want is still unusable if it crashes often or mutilates stored data.
Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.