Re: [gentoo-dev] Bugzilla etiquette suggestions

[Henrik Brix Andersen]

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 <brix@g.o>
Gentoo Metadistribution | Mobile computing herd