Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Is bug report a contribution?

by vsespb (Hermit)
on Oct 05, 2013 at 15:40 UTC ( #1057044=perlmeditation: print w/ replies, xml ) Need Help??

Here is a situation:

Someone reports a bug for an opensource software (say, CPAN module).

How would you treat that?
  1. This user helping this project - by reporting the bug user wants to make the project better. Often User does not need fix for the bug, because he/she don't depend on this project or because he/she can workaround the problem
  2. User asks for help. Fix for this bug would not help the project (because it worked fine previously, before this bug was reported, so, probably no one cares about this bug, except the one who reported it). If maintainer fix this bug, he/she would help the user
Of course in some cases answer is obvious:
It's definitely not help for project if bug report is bad. This is not help also if maintainer made a note elsewhere in documentation that project is obsolete/abandoned/no bugs fixed without patches

It's also obvious the user don't need help if he/she asks to fix typo in documentation or if the bug has obvious workaround.
but how do you treat this by default?

Sometimes I see users who like the project, but they don't report bugs (probably because they don't realise that this would help project author).
And sometimes (more often) I see maintainers who don't care much about quality of their software, or even those who tell (in private talk, not in project documentation) that they would never, never fix anything not directly affecting their own use of their software

Comment on Is bug report a contribution?
Re: Is bug report a contribution?
by toolic (Chancellor) on Oct 05, 2013 at 16:45 UTC
    Yes, a bug report is a worthwhile contribution.

    Yes, it is better to make a reasonable effort to prove there is a bug. Creating a small test case removes any ambiguity.

    Bug reports serve two purposes:

    • They make the author aware of the bug.
    • They make users aware of the bug.

    Even if the author does not fix the bug in a timely manner, perhaps one of the users may fix it by submitting a patch to the bug report.

    Documentation bug reports are valid, whether they be for incorrect information, missing information, typos or spelling errors. Again, this clears up ambiguities.

      There is actually a third purpose:

      Bug reports help the users who run into a problem to find out what circumstances trigger the bug.

      Often you google for an error message, and if the bug report states the preconditions/circumstances of the bug, that can often serve to find a workaround.

Re: Is bug report a contribution?
by moritz (Cardinal) on Oct 05, 2013 at 18:21 UTC

    Bug reports are important. They show that somebody cared enough about the project to go to the trouble to find the place where bug reports are submitted, and submitted the bug report.

    So if you, as an author, care about the project, its users and communities, you should treat bug reports (even for seemingly trivial things; for somebody else they aren't as trivial; hence the report) as a contribution.

    Just because some maintainers don't give a damn doesn't mean you should too.

Re: Is bug report a contribution?
by tobyink (Abbot) on Oct 06, 2013 at 10:01 UTC

    "User asks for help. Fix for this bug would not help the project"

    Actually even this kind of bug report can help the project - it can indicate an area where the provided documentation and examples are not clear enough.

    Of all my CPAN projects, there is one that I'd class as the most polished; it has a very extensive test suite and detailed documentation; it has a fairly large number of other CPAN projects that now depend on it, so by necessity now needs to provide a pretty stable interface. It's also the project I've had the most bug reports for; of the 31 reported on rt.cpan.org (there have been others reported to me on IRC, but I've not kept careful records of them, so for statistical purposes we'll consider only those on rt.cpan.org) there are only two that I don't think have helped move the project forward. That's a pretty high ratio.

    Where a bug report results in a change, I try to give thanks to the reporter in the "Changes" file.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re: Is bug report a contribution?
by DrHyde (Prior) on Oct 07, 2013 at 11:11 UTC

    Others have addressed most of the issues in your post, but not this

    "It's definitely not help for project if bug report is bad. This is not help also if maintainer made a note elsewhere in documentation that project is obsolete/abandoned/no bugs fixed without patches"

    Even if a bug report is wrong, or you've documented that the project is obsolete, abandoned, etc, you should still treat the reporter with courtesy and not just ignore them. Even though it costs you a few moments of time, you should do this for several reasons:

    • Rude people are less than fully human. When you are rude you destroy a little bit of yourself;
    • Your reputation. As an open source author you live or die by your reputation. If you are rude to someone when they are wrong, they are likely to tell others about your poor behaviour. And whether it be right or wrong, there is a perceived link between the quality of a person and the quality of his work.
    • Your reputation. Open source authors are also likely to be professional closed source authors. People who you are rude to aren't going to merely tell their friends, some of those friends are your potential future employers or customers.
    • If you're rude to people they won't bother to help you with correct bug reports in the future.

    Something as simple as "thankyou for your bug report. However, as documented, I can not accept your report because blah blah blah" is sufficient. As for users not reporting bugs, you can help them by providing easy links in the documentation to your bug tracker. Some people will still not bother, but any small increase in people telling you about problems is useful. Also put a link in your module's META.yml so that places like metacpan will link to the bug tracker.

      Many bug reports/tickets are posted in the wrong queue, because people don't/can't/won't analyze the actual *cause* of the problem.

      If module Foo::Bar is just a wrapper over Foo or a subclass of Foo, the problem might very well be hidden in Foo, way out of reach of the author to whose queue the bug was reported. Same for failures regarding system libraries malfunctioning (libxml2, libcrypto, ) or installed basic utilities with severe bugs (tar, cc, bash, ) for which the author of a module cannot be held responsible. IMHO a CPAN author may expect functional bash/cmd, tar, and cd.

      Sometime it is hard to be polite to ticket posters telling your module sucks because it doesn't work on their system, even if Makefile.PL and README specifically state that their system or configuration is not supported because of a very good reason (e.g. DBD::Oracle will not install if there are no Oracle client libraries available: that id NOT the fault of the author/maintainer of DBD::Oracle and it is very well documented. I really understand how it pisses them of if people post tickets like that.


      Enjoy, Have FUN! H.Merijn

        In case of the Foo::Bar subclassing/wrappig Foo, you as the author of Foo::Bar are in a much better position to forward the blame. You can't expect users of a "::Simple" wrapper to dissect the wrapper and guess all the preconditions and assertions you, the author of the "Foo::Simple", made about the "Foo" to find out whether there's something wrong with Foo or with the way you use it. And even if the problem is inside Foo, you usually do care. Even if the only thing you can do is to close it with "problem is in Foo, it was reported a year ago already".

        Regarding the other case ... if you can't be polite, don't be impolite. Just close the bug selecting "N/A" or similar reason.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

        I do understand how annoying things like that are - I get them all the time from people who seem to think that they should report bugs in Some::Module to me because I list that module's pre-requisites on CPANdeps. Nevertheless, I try to be gentle. It doesn't cost me much to point them at the right RT or github tracker.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1057044]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2014-12-22 05:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (110 votes), past polls