[Geany] Ideas for reducing duplicate bug reports

Cássio Nandi Citadin cassionandi at xxxxx
Fri Feb 3 17:25:53 UTC 2012


In fact, make a user to register in a new platform to report a bug make it
lost it focus on the bug itself with all registration and new passwords.
Its not fair said that someone who dont want to register doesn't have
valueable info about a issue.

2012/2/3 Matthew Brush <mbrush at codebrainz.ca>

> On 02/03/2012 03:57 AM, Lex Trotman wrote:
>
>> [...]
>>
>>> +1 to everything above. I reckon that many of those anonymous bug
>>>> reports are next to worthless for their minimal detail and that means
>>>> they end up reducing the signal to noise ratio. If someone isn't
>>>> already a member of either SF or GH and won't join up in order to
>>>> submit a bug report, what are the chances that the bug report is both
>>>> sufficiently detailed and not a duplicate?
>>>>
>>>
>>> I can tell only for myself: I found a couple of bugs on wordpress, and
>>> some misbehaviors und firefox and a couple others more. As the I'm
>>> forced to register a new account on their plattforms the mood to report
>>> went against 0 so a couple of them I just fixed locally and didn't
>>> report upstream. Shame on me. But I don't want to do a 10min register
>>> marathon just for reporting one line is suboptimal. I'm fine with a
>>> bigger number of noise, if there are a bunch of maybe new reports which
>>> we wouldn't get else wise.
>>>
>>>
>> I agree with Frank, registration tends to stop casual reporters, who
>> are not involved with the particular program but have found a problem.
>>
>> Certainly I will not bother to report a bug in software I am just
>> using, but not involved with, if I have to jump through hoops.  And
>> there is no way I remember what I used as a password last time I
>> registered to report a bug for [insert project here] so to report
>> again I have to go through the whole forgoten password fiasco.  Bah,
>> too much trouble.
>>
>>
> I'd agree somewhat for random Bugzilla/Trac installations where each one
> has a different login, but for something like SF.net or Github.com where
> there's only one login, it's much less of a problem. What's more, it takes
> like 1-3 minutes to reset a password, if you can't be bothered to spend a
> few minutes entering details for the bug report (in this case your contact
> info), what are the chances your report is going to be sufficiently
> detailed? And what are the chances that you're going to go back to the bug
> report, which doesn't know your email address to tell you of new comments,
> and follow up with additional testing, etc?
>
>
>  Admittedly casual reports are varying quality, from ones where you
>> want to shout "RTFM", to completely professional.  Just because the
>> reporter didn't register does not imply any lack of intelligence or
>> knowledge.
>>
>>
> But it often implies lack of care or follow through, or in the case of
> SF.net that you might've forgotten to login because it's not required :)
>
>
>  Perhaps we just need to be a little more proactive in closing them,
>> after all they don't actually go away and it shows an actuve bug
>> processing culture.
>>
>>
> I see lots of active bug processing on Launchpad.net and various Bugzillas
> despite them requiring a login. They have a certain minimum amount of
> information needed to start working on a bug, and that includes the
> reporters contact information.
>
> Cheers,
> Matthew Brush
>
> ______________________________**_________________
> Geany mailing list
> Geany at uvena.de
> https://lists.uvena.de/cgi-**bin/mailman/listinfo/geany<https://lists.uvena.de/cgi-bin/mailman/listinfo/geany>
>



-- 
Cordialmente,
   Cássio Nandi Citadin  -  cassionandi at gmail.com
    @cassionandi <https://twitter.com/#%21/cassionandi>  -
http://cassionandi.blogspot.com
   (48) 9921-9991

Não basta ser agora, tem que ser pra Jah!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20120203/3ffbfa6e/attachment.html>


More information about the Users mailing list