launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/8/16 Karl Fogel <karl.fogel@xxxxxxxxxxxxx>:
> When responding to a bug report, many of us now say like "This should be
> easy to fix.  Here is where to start, and I'm happy to help anyone who
> works on this ...".
>
> This is great, but remember that many readers will not know that
> Launchpad is open source, so they'll think that the "anyone" being
> addressed is other current developers.  They won't necessarily realize
> that "anyone" could mean them.
>
> So be very direct: state that Launchpad is open source, and link to
> https://dev.launchpad.net/.  For example, see:
>
>  https://bugs.edge.launchpad.net/ddtp-ubuntu/+bug/374966
>  https://bugs.edge.launchpad.net/rosetta/+bug/394923
>
> I've updated https://dev.launchpad.net/BugHandling to recommend this.
> And remember Maris's 1000/10/1 rule: 1 patch for every 10 commentors and
> every 1000 viewers.  Most encouragements won't lead to a patch -- but
> some will, and they makes all the others worth it.

I think that there's a lot of value in getting more people to help
with fixing bugs, but I wonder if that value outweighs the problems
with adding notes like that.

1. Bug comments are primarily there for adding information that
pertains to the bug itself - how is the bug manifested, how can it be
reproduced, how should it be fixed, how can the fix be verified,
etc'... Any "meta" comment you add detracts from the value of bug
comments and makes it more difficult to find the relevant information,
so if at all possible, it should be avoided.

2. Many people are subscribed to bug mail and get notified whenever a
new comment is posted. Any comment that's not directly relevant to the
discussion of the bug is for them as good as spam. It requires a bit
of effort on their part to read and understand and leaves them
irritated when they realize they didn't gain any new information that
they find helpful. This is often unavoidable, but whenever we can we
should try and avoid doing that.

You mention the 1000/10/1 rule which I think is very true in this
case, but it has other consequences which you didn't mention: whenever
you post a comment like that you get the attention of 1 potential
contributor at the cost of annoying 1000 users who are unlikely to
participate in development.

Learning how to work with the Launchpad codebase and contributing a
fix requires quite a lot of effort. The essence of spam is when you
try to elicit a large expenditure without yourself making an
investment that is proportional. A friendlier model is one where you
are willing to invest more when you seek high-bandwidth participation.
For economical reasons, you must do that less often, which results in
lower volume correspondence. That, in turn, forces you to choose
"targets" with a higher likelihood of success, to optimize ROI. I
think that getting people to participate in development is better done
by identifying individual users and user groups which we think are
likely to want to jump in, go after them (politely) and offer help.
This requires a lot more effort on our part, but we're likely to get a
much better success ratio than 1000:1.

Tom