This user helping this project - by reporting the bug user wants to make the project better. Often User does not need fix for the bug, because he/she don't depend on this project or because he/she can workaround the problem

User asks for help. Fix for this bug would not help the project (because it worked fine previously, before this bug was reported, so, probably no one cares about this bug, except the one who reported it). If maintainer fix this bug, he/she would help the user

Of course in some cases answer is obvious:
It's definitely not help for project if bug report is bad. This is not help also if maintainer made a note elsewhere
in documentation that project is obsolete/abandoned/no bugs fixed without patches

It's also obvious the user don't need help if he/she asks to fix typo in documentation or if the bug has obvious workaround.
but how do you treat this by default?

Sometimes I see users who like the project, but they don't report bugs (probably because they don't realise that this would help project author).
And sometimes (more often) I see maintainers who don't care much about quality of their software, or even those who tell (in private talk, not in project documentation) that they would never, never fix anything not directly affecting their own use of their software

Bug reports are important. They show that somebody cared enough about the project to go to the trouble to find the place where bug reports are submitted, and submitted the bug report.

So if you, as an author, care about the project, its users and communities, you should treat bug reports (even for seemingly trivial things; for somebody else they aren't as trivial; hence the report) as a contribution.

Just because some maintainers don't give a damn doesn't mean you should too.

Actually even this kind of bug report can help the project - it can indicate an area where the provided documentation and examples are not clear enough.

Of all my CPAN projects, there is one that I'd class as the most polished; it has a very extensive test suite and detailed documentation; it has a fairly large number of other CPAN projects that now depend on it, so by necessity now needs to provide a pretty stable interface. It's also the project I've had the most bug reports for; of the 31 reported on rt.cpan.org (there have been others reported to me on IRC, but I've not kept careful records of them, so for statistical purposes we'll consider only those on rt.cpan.org) there are only two that I don't think have helped move the project forward. That's a pretty high ratio.

Where a bug report results in a change, I try to give thanks to the reporter in the "Changes" file.

"It's definitely not help for project if bug report is bad. This is not help also if maintainer made a note elsewhere in documentation that project is obsolete/abandoned/no bugs fixed without patches"

Even if a bug report is wrong, or you've documented that the project is obsolete, abandoned, etc, you should still treat the reporter with courtesy and not just ignore them. Even though it costs you a few moments of time, you should do this for several reasons:

Rude people are less than fully human. When you are rude you destroy a little bit of yourself;

Your reputation. As an open source author you live or die by your reputation. If you are rude to someone when they are wrong, they are likely to tell others about your poor behaviour. And whether it be right or wrong, there is a perceived link between the quality of a person and the quality of his work.

Your reputation. Open source authors are also likely to be professional closed source authors. People who you are rude to aren't going to merely tell their friends, some of those friends are your potential future employers or customers.

If you're rude to people they won't bother to help you with correct bug reports in the future.

Something as simple as "thankyou for your bug report. However, as documented, I can not accept your report because blah blah blah" is sufficient. As for users not reporting bugs, you can help them by providing easy links in the documentation to your bug tracker. Some people will still not bother, but any small increase in people telling you about problems is useful. Also put a link in your module's META.yml so that places like metacpan will link to the bug tracker.

Many bug reports/tickets are posted in the wrong queue, because people don't/can't/won't analyze the actual *cause* of the problem.

If module Foo::Bar is just a wrapper over Foo or a subclass of Foo, the problem might very well be hidden in Foo, way out of reach of the author to whose queue the bug was reported. Same for failures regarding system libraries malfunctioning (libxml2, libcrypto, …) or installed basic utilities with severe bugs (tar, cc, bash, …) for which the author of a module cannot be held responsible. IMHO a CPAN author may expect functional bash/cmd, tar, and cd.

Sometime it is hard to be polite to ticket posters telling your module sucks because it doesn't work on their system, even if Makefile.PL and README specifically state that their system or configuration is not supported because of a very good reason (e.g. DBD::Oracle will not install if there are no Oracle client libraries available: that id NOT the fault of the author/maintainer of DBD::Oracle and it is very well documented. I really understand how it pisses them of if people post tickets like that.

In case of the Foo::Bar subclassing/wrappig Foo, you as the author of Foo::Bar are in a much better position to forward the blame. You can't expect users of a "::Simple" wrapper to dissect the wrapper and guess all the preconditions and assertions you, the author of the "Foo::Simple", made about the "Foo" to find out whether there's something wrong with Foo or with the way you use it. And even if the problem is inside Foo, you usually do care. Even if the only thing you can do is to close it with "problem is in Foo, it was reported a year ago already".

Regarding the other case ... if you can't be polite, don't be impolite. Just close the bug selecting "N/A" or similar reason.

I do understand how annoying things like that are - I get them all the time from people who seem to think that they should report bugs in Some::Module to me because I list that module's pre-requisites on CPANdeps. Nevertheless, I try to be gentle. It doesn't cost me much to point them at the right RT or github tracker.

Ada Lovelace for the palindrome
Albert Einstein for having smelly feet
Alfred Nobel for his contribution to battlefield science
Burkhard Heim for providing the missing link between science and mysticism
Claude Shannnon for riding a unicycle at night at MIT
Donald Knuth for being such a great organist
Edward Teller for being the template for Dr. Strangelove
Edwin Hubble for pretending to be a pipe-smoking English gentleman
Erwin Schrödinger for cruelty to cats
Hedy Lamarr for weaponizing pianos
Hugh Everett for immortality, especially for cats
Isaac Newton for his occult studies
Kikunae Ikeda for discovering the secrets of soy sauce
Larry Wall for his website
Louis Camille Maillard for discovering why steaks taste good
Marie Curie for the shiny stuff
Nikola Tesla for the cool cars
Paul Dirac for speaking one word per hour when socializing
Richard Feynman for his bongo skills
Robert Oppenheimer for his in-depth knowledge of the Bhagavad Gita
Rusi P Taleyarkhan for Cold Fusion
Sigmund Freud for his Ménage à trois
Theodor W Adorno for his contribution to the reception of jazz
Wilhelm Röntgen for the foundations of body scanners
Yulii Borisovich Khariton for the Tsar Bomba
Other (please explain why)