Thanks for replying, I appreciate hearing back from you so
I've moved your service from the "Possibly evil"
category, to the "Well intentioned" category in my mind. :-)
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
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
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" ?
Just tell us and we'll do our best to
On Tue, May 12, 2009 at 5:03 AM, Jason Cleeland <firstname.lastname@example.org>
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
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
I'd love to know your rationale and