Hi Gabi,
Thanks for replying, I appreciate hearing back from you so quickly!
I've moved your service from the "Possibly evil" category, to the "Well intentioned" category in my mind. :-) Phew.
I don't know how your system works, but if I were to be able to set your service up the way I wanted to, I would have it only report any of our bugs if their status was:
"Acknowledged", "Confirmed" or "Assigned"
As far as I know "new" will be the status immediately after the bug report is created. "Feedback" will be the status after someone has posted a comment. So "Feedback" doesn't indicate whether a bug has been verified.
Those statuses generally will occur at points where one of our development team has made an assessment of the issue and had an opportunity to revise the "Severity" of the bug. I assume that your system uses the severity setting to determine the message it provides.
I think you should make the severity message you show less authoritative. Instead of "Major", it should say "Reported as major", to indicate that this is not necesarily verified by yourselves, and that you are using the self-reporting tools of the projects themselves, and that they're not verfied as correct.
I assume that you don't list those bugs that have a view status of "Private".
To be honest, I think I'll be recommending to our development team and project leader that we change the default setting of all new bugs to "view status"="private" so that you can't report on them at all until we've verified the bugs. Which is sad for us, because we are an open project - but I think your reports could be unfairly damaging to our projects public image.
Jason Cleeland

From: Gabi [mailto:bugspynet@gmail.com]
Sent: Wednesday, 13 May 2009 12:55 AM
To: Jason Cleeland
Subject: Re:

Hi Jason

Thanks for the feedback.
There hundreds of thousands of bug reports, but we really try our best to produce relevant info and not garbage. 
In your particular case we use http://bugs.limesurvey.org/csv_export.php to find reports. Maybe we could use  the "status" field to filter out unconfirmed bugs? which status suggests the bug is not confirmed? "new" ? "feedback" ?
Just tell us and we'll do our best to fix


On Tue, May 12, 2009 at 5:03 AM, Jason Cleeland <jason@cleeland.org> wrote:
Dear BugSpyNet,
You post bug alerts as "major" and "stopper" even before the bug is confirmed. There are two limesurvey bugalerts you've issued which - at first glance to me - seem to be configuration / user configuration errors, and have not been confirmed as bugs.
Is that the way you report all your bugs? You just repeat anything that gets posted in a bug tracking tool without even investigating?
The reason I ask is because if you are serious about informing the Open Source community about actual bugs in software then I think you ought to investigate the bug report before assigning it as a "Stopper" or "Major". Quite often bugs will be posted by users who have simply not read the instruction manual, and the bug isn't really a bug at all. In these cases, re-broadcasting the bug across major networks like twitter as a "Stopper" or "Major", when they're actually not, is spreading mis-information and acting as a disincentive for the public to seriously try out good, high quality open source software.
I'm a bit annoyed because they come up after a search for our software in LimeSurvey, and all the bugs you've reported are non-confirmed bugs, which after my brief investigation are actually not confirmed bugs at all and probably just user misconfigurations. I don't have a problem with users misconfiguring things, and we're happy to help these people set up their installations correctly, but it's hardly fair to be dis-encouraging others from trying out LimeSurvey because some of our hundreds of thousands of users have unusual server installations, or have missed some of the steps in the installation guide!
The fact that each bug is listed as "Stopper" or "Major" indicates that someone somewhere is actually doing a quick review. But they're apparently doing it rather poorly.
I'd love to know your rationale and processes here.

Jason Cleeland