← Back to team overview

launchpad-dev team mailing list archive

Re: Turning bug reporters into patchers.

 

On 09-08-03 01:01 AM, Karl Fogel wrote:
This is for everyone here who ever responds in bug reports:

Let's please try to use each bug report as an opportunity to let the
reporter know that they might be able to fix the bug themselves!

Many reporters may not even know that Launchpad is open source, so be
sure to point that out and refer them to dev.launchpad.net.  If they
grab the Launchpad source code and have a look, who knows -- they may
try their hand at fixing the bug.  I've certainly seen this technique
work in other open source projects; it might work here too.


It is certainly worth a try.

The way to do is something like this, I think:

  "Thanks for the bug report.  Yes, I can confirm that I see this too.
   If you would like to help fix it, please visit dev.launchpad.net to
   get the code to Launchpad (it's open source), and if you have
   questions, post to the launchpad-dev mailing list -- many people
   there will be glad to help anyone who's trying to fix a bug.  But
   don't worry if you don't have the time or expertise to do that; the
   bug will still enter our normal triage system and someone else will
   get to it eventually.

   [...more discussion about the bug, workarounds, etc, here...]"


Is it necessary to post all of the instructions? Or is it enough for a core developer to say:

  "This is an easy fix, just
   A)...,
   B)...,
   C)...,

   I'll sponsor anyone who wants to submit a patch."

You need to respond with a clear, authoritative statement that it is easy to fix, clear steps to fix it, and that a core contributor's help is available. And I really think all three parts are necessary.

I've seen a similar pattern in Mozilla and Gnome bugs, and people do respond with patches. But anecdotally it follows the 1000/10/1 rule: you'll get one patch for every 10 commentors, and every 1000 viewers :)

Maris

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References