It's a tough balance. You start a one-dev project for free that gets big, suddenly it's next to impossible to keep up with support requests.

If your project is targeted at developers, you might be able to find someone you can trust to help you out, but if it's targeted at non-technical users that's like finding a unicorn.

I'm not arguing in favor of keeping people out of course, just that it's not as straightforward as "issue templates bad" vs "RTFM noob".

It sounds a bit like the opposite side of the customer acquisition cost versus lifetime value.

Traditionally if you have a high user lifetime value you can spend more money on getting more customers by increasing your marketing spend so your CAC (customer acquisition cost)/LTV (lifetime value) stays at a good level. So you can keep a good growth curve.

In this case when your ltv is negative for each issue because of low quality, or simply too many of them then you make it harder for new issues to come in, which should ideally result in fewer but higher quality reports?

I have a question mark in there because I did not spend a lot of time considering this, but I like the thought.

yeah, I understand the practical side of the problem and is certainly not easy as you say. as for issue templates, reporting guidelines etc., they make it even less likely that people report a problem. as the article mentions, even on a project that encouraged feedback it was still not reported that it doesn't run on the mac. so my takeaway is that there shouldn't be any guidelines for issue reporting if someone wants to catch even a glimpse of the real issues. I'd say there should be a good process in line that deals with the issues and asks for necessary information afterwards, so potential reporters are not driven away by issue requirements. knowing this I'd say projects that have issue guidelines hurt themselves in the end.

People sometimes add unnecessary difficulty to the process of reporting a bug. But there's also some unavoidable difficulty.

You need to gather some good information, You need to explain it in terms that are understandable, and you probably ought to put a little effort into making sure you weren't creating a duplicate bug.

Not that that invalidates your point. It's enough work on its own without adding extra unnecessary work.

I agree, what I was getting at was that requiring detailed information upfront is going to give you even less reports, so it is advisable to get the information you need afterwards as I explained here:

https://news.ycombinator.com/item?id=21430124

And then you get people complaining about being asked to provide additional details. You can find some of them in this thread.

Some people don't want your feedback, and that's ok.