
The best bug reports are pull requests - rayvega
http://ayende.com/Blog/archive/2011/01/27/the-best-bug-reports-are-pull-requests.aspx
======
jjcm
A friend of mine has a little poster by his wall that says, "Stacktrace or
GTFO" for all people who give him bug reports. It follows the same mentality
as this - the more resources you can provide a developer for a bug report, the
a.) faster it'll be fixed and b.) the happier the developer will be. I think
you're right though, a pull request is pretty much like spoon feeding the bug
to the developer. That said, I think he's right in that it might clutter up
the repo a bit with bug examples - if pull reqs for bugs become common place
(and I hope they do) it'd be nice to have a way to classify them as such (or
perhaps there is a way that I don't know about yet?).

~~~
ars
Some developers have a mentality that if not enough information was provided
in the bug report then it's not a real bug.

They are wrong.

Just because you didn't get enough information to reproduce and/or fix it,
doesn't mean it's not there.

But, it does mean there is nothing you can can do about it. (Obviously try to
get clarification and more info, etc. this is assuming you were not able to.)

Nevertheless, in the back of your mind you should try to remember the bug and
maybe you'll come across something that will let you figure out what it was.

This doesn't scale so well for OSS projects, but if it's paid work and the bug
came from your client then you better track such things, even if you can't
immediately fix them.

~~~
Natsu
I get both ends of this.

On one side, I have trouble getting information out of people ("It had an
error" ... "What did it do?" ... "I don't know anything about computers, so I
clicked okay. Can't you just fix it?") and on the other, some of the people I
report things to aren't willing to even try to reproduce bugs ("I need 8,000
different files, screenshots, etc. of the bug in action, which will require
you to shut down production for an hour" ... "Can't you just look at the code
for X? It fails every time with the same behavior." ... "No, I really need you
to waste a lot of time on this because I'm way too busy to implement any kind
of logging." ... "No wonder you won't let anyone else have access to your bug
tracker. Something tells me it's a sticky note or whiteboard based system.")

I completely understand how people can fail to report enough information to
give anyone any hope of finding the bug, but it's frustrating when you know
you've got a good bug report and the developer doesn't want to listen to you.

------
wccrawford
In general, when I have an issue, I try to produce a small snippet of code
that shows the problem. I haven't done it as a unit test before, but I don't
think I've ever submitted a bug report to a project that has them...

It helps both me and the developer, because the developer can run the code and
see if he fixed -my- problem, rather than -a- problem, and I can run it
afterwards to verify that it's fixed. I've also had it show that the same code
will hit many bugs before it works... This allows the developer to fix it all
the way down.

------
adamesque
*pull requests containing a new, failing test. Love it.

