Bug report prelude

[Michael Glaesemann <grzm(at)seespotcode(dot)net>]

Hi!

I've only recently subscribed to the bugs mailing list, but I've  
noticed that a fairly high percentage of submissions are not actually  
bug reports, but requests for help. Looking at the bug report form,  
there is a request to review the bug reporting guidelines, but I  
thought it might help to put a brief bit of info up front. I was  
thinking of something like this:

<p>In particular, please re-read the <a href="/docs/current/ 
static/'>documentation</a> to verify that what you are trying is  
possible. If the documentation is not clear, please report that, too;  
it is a documentation bug. If a program does something different from  
what the documentation says, that is also a bug.</p>

<p>Poor performance is not necessarily a bug. Read the documentation  
or ask on one of the <a href="/community/lists/">mailing lists</a>  
for help in tuning your applications. Failing to comply to the SQL  
standard is not necessarily a bug either, unless compliance for the  
specific feature is explicitly claimed.</p>

<p>Before you continue, check on the <a href="/docs/ 
faqs.TODO.html">TODO list</a> and in the <a href="/docs/faq/">FAQ</a>  
to see if your bug is already known. If you cannot decode the  
information on the TODO list, report your problem so we can clarify  
the TODO list.</p>

Granted, there will always be bug reports which really aren't, but  
perhaps this might cut down on the number by helping those who might  
be better served using information we already have available.

What do you think?

Michael Glaesemann
grzm seespotcode net