launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/8/16 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.)

Yes, I agree. If you're already making a comment describing how to a
the bug, and are offering help to anyone wishing to fix it, the format
you suggested indeed looks optimal. I'll definitely make use of it in
such cases.

Tom