2009/8/16 Karl Fogel <[email protected]>: > Tom Berger <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
