I used to raise bugs with as much information as possible to reproduce or provide patches for the fix myself but these days more often than not I do neither.

I have found that a lot of open source projects really don't want any form of feedback or contribution at all and you sometimes just get abuse for even trying to help. I usually check the history of issues and pull requests to see if there is any chance its worthwhile doing them, more often than not it isn't. Definitely check beforehand how the project usually behaves before applying any effort because the bulk of them are not going to accept anything you might do if you aren't a committer.

I submit PRs. If the author doesn't want them, that's fine, I'll keep them in my own fork. If they do, win/win.

One of the very funny things I've found is that proprietary freeware devs are often much more receptive to feedback than open source authors. Rick Brewster (paint.net dev) for example has responded quickly to all of my emails, I also remember Discord being very responsive back in the day (2017-2018), no idea what they're like now.

> I stay quiet

I send a few words of encouragement describing how awesome the author's software is, and how it made my life (easier). Most seem to be happy to receive such feedback, some don't care. It hurts no-one either way and only takes a couple of minutes.

I appreciated your post, it's good advice.

What is constructive user feedback? That doesn’t help the software become better?

Not that the original email was that, necessarily. But in general.

We have such a code-obsessive—and elitist too—view of “contributing”. Oh so you are not gonna learn a new build system, a new programming language, our code guideline, and how to use our pull request checklist? Tsk tsk, then it’s not interesting to us that people with astigmatism can’t read the texts in our popups.

Per its definition: constructive user feedback should make the developer's work easier, not more difficult. Swearing is obviously bad (maybe not so obvious to some people). Screenshots, steps for reproduction, expected and actual behavior are the minimum, together with willingness to answer questions and try potential workarounds and solutions. Checklists are usually introduced after experiences with unhelpful tickets and PRs.

Granted, not all open source developer might be good at interacting with users. But expectations should be very low since volunteer developers only have limited resoures to spend per user. And companies behind open source projects obviously prioritize their paying customers.

Yes and no. Helpful and constructive feedback is helping, especially if you can communicate with technical / product awareness.

Most user won't recognize a (possible) bug. Of those a small percentage will consider mentioning it. Even fewer will actually follow through.

Writing a rude, demanding, and insulting rant is not being helpful. Even when the content can, theoretically, be helpful, the psychological cost on someone who is doing this for free is really too much. Its a great way to get the maintainer to quit.

I didn't say it was. I was commenting on the comment above me and pointing out that honest feedback can be a form of help. It doesn't have to be a PR.

Feedback is useful.

If you find a bug or think that something could really be improved it's fine, and in fact helpful, to give feedback. The key is always the phrasing and tone.