Hi, On Sun, Feb 12, 2006 at 09:11:33PM +0000, Daniel Drake wrote: > 2. Be careful with INVALID resolutions > > The term invalid _is_ harsh in bugzilla context, so make sure you write > a quick thankful-sounding comment to go with it. > > Maybe we should consider alternatives. I quite like the NOTABUG > resolution they have on the GNOME bugzilla.
I second that. I've always missed the not-so-harsh-sounding NOTABUG resolution I used to use so frequently back when I used gnome bugzilla on a daily basis. > 3. Always record contributions by name > > If you commit something in response to a bug report that has been filed, > always thank the user by full name (and bug number) in the ChangeLog and > commit message. > > Do the above even if you already knew about the bug (i.e. you would have > committed the same fix even if the user hadn't alerted you). > > This also applies for ebuild requests, ebuild submissions, and version > bump requests/submissions. Might sound pointless for 'trivial' > reports/requests but it is important to credit the user if they have > gone to the trouble of filing a bug. I don't really get this part. Why should I give credit to someone else for providing a fix for a bug which I already fixed myself locally? Why should I give credit to a user who filed a version bump request two hours after release and more or less doubled my work in actually performing the version bump? I fear the above policy will only lead to more pointless bugs being filed by the rare end-users who seem to like seeing their own name on print... > This also applies to contributors who you know well, contributors who > you have named 9999 times before, and other Gentoo developers too. Credit where credit is due, of course. Ebuild submissions, well thought-out and well-tested patches, problem analysis and similar should of course be credited - but to credit each and every user who just happened to be the first to file an enhancement request for version bump? First post, anyone? > 4. Give the user a chance to make minor corrections > > If a user contributes a patch/ebuild which is slightly wrong, and the > issue is non-critical, don't immediately correct it on their behalf and > commit it to get the bug out of the way. > > Instead, provide an explanation of their mistake and give the user a day > or two to correct it and attach an updated version. This has the bonuses > that the user definately won't repeat that mistake in future > contributions, and they will have the nice feeling of full credit for > the contribution after you name them in the ChangeLog :) > > If they don't respond in that time, make the correction yourself and > commit it anyway. This will also double if not tripple my work-load. I understand the motivation for this, but let's face it: developers are here for the fun too - personally I am not here to educate end-users about minor details which they might as well have read up on first by themselves. I know that may sound harsh, it's not meant that way. I just think I have more important things to spend my time on than first writing a small essay on how the user could improve his work, then discuss the details, then realize that I need to put in the changes myself after all since the user didn't respong within a given time period - and last but not least, test and commit the stuff to CVS (Rather than just making the small changes required, test and commit). > 5. Be thankful when marking FIXED > > When marking a bug as FIXED, I often forget that the user has tested 4 > kernel versions, moved their network card over to another computer, > filed an identical bug report upstream, tested the solution, and > reported back to me. > > I think a short note of thanks in the bugzilla comment can go a long way > (suggestion: thank them for something in particular so that it doesn't > sound so generic). Agreed. I always try to remember posting a small thank you note when closing a bug. Often it ends up as a pretty generic note, though. I'll try to improve that :) Just my thoughts on the above. All in all a good summary/reminder about our behavior towards end-users who are being/trying to be helpful. Thank you for taking the time to write it up. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd
pgp6sNqrncoEX.pgp
Description: PGP signature
