launchpad-dev team mailing list archive

[Karl Fogel <karl.fogel@xxxxxxxxxxxxx>]

Tom Berger <tom.berger@xxxxxxxxxxxxx> writes:
> 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.

Half agree?

I think you've got a very good point, in that I was overeager in adding
those new comments -- their "distraction cost" is too high.

But in the first response to a report, it is still very worthwhile to
solicit coding help (except when it's obvious that the reporter is not a
good candidate).  That is, the real penalty here is the additional
email/comment.  Adding an additional "noise event" should be avoided,
you're absolutely right.  But in a response comment that one is making
anyway (such as the two Danilo made in those examples I gave), it's
useful to follow the https://dev.launchpad.net/BugHandling guidelines.

(Maybe that's what you were saying too?  I wasn't sure.)

-Karl