Did you ever think about who those developers are you want to reach ? Those are OSS developer who work in their free time on a project. They work on it because it's fun to do it. But reading shitty bugreports and trying to read stupid "it does not work" peoples minds is no fun at all.
And mind you, i've done it, i've done it for a long time, every day 1 to 5 (!) hours. Most time telling people to read the bug submission procedure (which is neither hard to find nor hard to read) or those who claim to have read it to read again and try to understand what it really says.
When it wasn't this, i told them to read the FAQ as their "bug" was already covered there (mostly for several months) or to simply have a look at the documentation as it explains what they did wrong.
Overall not even 1% of the "bugreports" were actual bugs but simple PEBCAK which could be easily solved by just taking their time to read the documentation even a grep would have shown the solution in most cases.
As i said, i did this for a long time several hours a day. I never counted how much time i worked for others, solving their problems w/o being paid for it. I did it and i don't regret it, but i also stopped it because seeing that nobody ready your mails about how a bugreport should be send just plainly sucks.
Thus IMHO you should rethink what you wrote and rather adress those who send bugreports. To tell them to use their common sense and their brain. It's not hard to write a proper bugreport, but just a few seem to be able to do so.
1) Get a clue what happend.
Did your app crash ? Did it do something you did not expect ? What might have caused this ? Can you reproduce it ?
2) READ and UNDERSTAND the error message
I'm sure there is one. Also switching verbose mode on and trying again might be a good idea to know what the app was actualy doing.
3) Read the documentation
Start from the FAQ and read all parts of the documentation that seem even remotly relevant and most importantly try to understand them. In most cases you can solve your problem by this yourself.
4) Narrow down what the problem is
Try again with different settings/options/files and try to narrow down the submodule which might cause the problem. It's a difference to know whether it was the "whole program" or just a small part of it that might doing something wrong.
5) Type your error message/problem description into google
You might laugh, but just a c&p of the error message into google will get you a few hits of people who already had the same problem with possible solutions.
6) Find the bug submission procedure of your application
Most projects have a section of their documentation devoted to reporting bugs. Read it, understand it, read it again. Then follow it precisely and word for word, don't think about it, just do as it says whatever it might be. There is a reason why the developers wrote that.
7) Write the bugreport to the proper place
Most projects have a user mailinglist, a bugs mailinglist or a bugtracker. Find it and use it. NEVER write to a developer directly, never ever. They are already burried in thousands of mails, they dont need another one to send to /dev/null. Also follow the guidelines about proper mail formating (not more than 70 characters per line, no html, no big attachments) and NEVER press "reply" on another mail if you start a new thread, people will shot you for this and most probably your mail will get lost in the other thread.
Don't be hasty little hobbits. Those are humans with a life outside the world of bits and bytes. They have a work, a family, friends and lots of other things to do. It may take a few days or even weeks until someone responds to your bugreport.
9) Providing additional information
If you are asked to provide additional information or to try something, then you should write a reply to the mail which is a) properly formated (the things mentioned above plus proper quoting, NO TOFU!) and b) with correct mail headers that provide In-Reply-To and References fields. Don't use broken shit like Webmailers or Outlook, they just break the thread and the other side will have a hard time to get what your previous mail was about.
10) Send a thank you
If someone took a lot of time to help you with your problem than you should thank him
Sometimes i think that we should charge everyone sending a bugreport a few dollars, just to cover those 5 minutes it takes to quickly read his bugreport. Maybe then they'll think twice about writing "it does not work, please help me". Beside, it would cover the costs of buying new hardware for the servers or maybe even make us rich :)