[gentoo-dev] Bugzilla etiquette suggestions

[gentoo-dev] Bugzilla etiquette suggestions

[Daniel Drake]

I wrote most of this a while ago but didn't get round to finishing it. 
This seems appropriate at this time, so here it is :)

Here are some small *suggestions* for how I think we can motivate users 
on Bugzilla to contribute more, and to contribute more often. I'm not 
suggesting this be enforced as policy, but it would be nice to see other 
developers giving this some thought. I'm far from perfect here, but I am 
working on sticking to my own suggestions more and more.

Remember that Bugzilla is the only way we communicate with most of our 
external contributors so it is important to make them feel appreciated 
and give them a good impression of the Gentoo developer community.

1. Don't bitch at contributors

Even if they did something totally wrong, violated all known policies, 
and you are *sure* they just filed the bug to annoy you, don't write 
aggressive sounding responses.

Reasons being:
- You'll reduce the chances they'll think about contributing again in 
the future
- They probably won't listen to a word you say, yet will feel the need 
to respond
- Bugzilla is a public medium, and other potential contributors (who 
maybe wouldn't have made such 'obvious' mistakes) will be put off when 
reading the aggressive dialog.
(I'm not suggesting that you send abuse privately instead!)
- Like we aren't paid to fix bugs, the users aren't paid to file them: 
at the end of the day, someone went out of his/her way to file the bug, 
to try and help.

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.

Marking bugs as duplicates is also dodgy ground: Comments like "Please 
search" can easily be taken the wrong way. I'm probably asking too much 
for people to spend lots of time thinking up appreciative duplicate 
messages, however...

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.

This also applies to contributors who you know well, contributors who 
you have named 9999 times before, and other Gentoo developers too.

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.

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).

6. Don't forget about email

As a Gentoo developer, you have been automatically granted the ability 
to sound important and make others feel important too.

When Seemant mailed me over 2 years ago, I was a relative idiot and was 
a new Gentoo user at that time. It felt great to receive a complimentary 
email from a well-known and respected Gentoo developer, and that email 
eventually led to me becoming a developer myself (amongst other things!).

I've had the same kind of effect on people since then, for example, I 
sent a very quick "thanks" mail to the guy who authored the wordpress 
theme I run on my weblog, and he was overjoyed that I was using it - he 
happened to be a Gentoo user who already read my blog via the Planet site.

There probably aren't many situations where you would email a user who 
communicates with you on bugzilla. But don't forget about this nice 
ability that we have :)



That's all I can think of for now. I'd certainly be interested to hear 
any comments on the above and similar suggestions that others may have.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 4460 bytes --]

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@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Daniel Drake]

Henrik Brix Andersen wrote:
>> 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?

Maybe not if you have already done the work. I was thinking more of the 
scenario, upstream does a release. You are on the mailing list so you 
know about the new version. You decide you'll bump it in portage tomorrow.

Overnight, someone files a request for a version bump. Maybe they attach 
a new ebuild or state that the existing one needs bumping.

Even though you knew about it, I was suggesting that you credit the user 
for filing the bug.

I'm not sure of the best way to handle the situation where the user 
files a bug that you have already solved 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'd say doubling is a bit of an exaggeration, since it really isn't that 
much work to mark a bug fixed. Not that bumping an ebuild is complicated 
anyway.

The issue I am trying to approach is that the user who filed the bug is 
likely to check the ChangeLog, and will be mildly upset if they are not 
mentioned yet it appears that their bug report *may* have triggered the 
bump.

Put another way, what is the harm of putting a name in the ChangeLog 
when it may motivate that person to contribute more? The "damage" (them 
filing the bug, when you didn't strictly need it) is already done, and 
by showing them this kind of respect they hopefully won't repeat their 
"mistake".

> 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?

"Gentoo is like a drug"

Indeed, if enforced globally then we might end up with a situation like 
that and something would need to be done. I somehow doubt that would be 
the case. But people racing to contribute would also have its desirable 
effects :)

>> 4. Give the user a chance to make minor corrections
> 
> 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.

That is a fair point, and if you can't afford to spend the time on it 
then I'm not complaining. However, there are situations where this can 
*save* you time. One example that springs to mind:

http://bugs.gentoo.org/119178

- I have very little clue about jfsutils
- I suck at ebuilds
- I know of flag-o-matic's existence but had no clue how to use it

It obviously didn't take me much time to add the comments that I wrote 
there, and it definitely saved me time in solving the bug, and educated 
me as well.

> 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.

Thanks for the feedback. Indeed it does have some "perfect world" 
implications, but I'm not suggesting this should happen every time 
everywhere. I just think that more consideration in this area would make 
a real difference.

On a similar note, I received a very interesting book as a birthday 
present last year. It's called "How to win friends and influence people" 
by Dale Carnegie and can be picked up very cheaply at any decent 
bookshop. That probably indirectly influenced some of the above - highly 
recommended for people interested in motivating others.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 12 Feb 2006, Daniel Drake wrote:

> Henrik Brix Andersen wrote:
>> >  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?
>
> Maybe not if you have already done the work. I was thinking more of the 
> scenario, upstream does a release. You are on the mailing list so you know 
> about the new version. You decide you'll bump it in portage tomorrow.
>

Well, the user did the work, too, and doesn't know that you did it (if I 
understand your case correctly).  So the user deserves as much credit as you do.

(At least, from the user's point of view.  Consider, if you don't credit 
the user, to the user it just looks like you took the fix and called it 
your own.  You know that's not the case, but the user doesn't and likely 
is justifiably upset.)

> The issue I am trying to approach is that the user who filed the bug is 
> likely to check the ChangeLog, and will be mildly upset if they are not 
> mentioned yet it appears that their bug report *may* have triggered the bump.
>

By the way, I really like the proposal which triggered this discussion.

Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD79mAQa6M3+I///cRAlZMAJ9F8sew14KN4jmdqwHHVVFrQcYdnwCeMTcD
r9bihtdF/W7cU8bqMy1OEM8=
=p+Fd
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Mon, 13 Feb 2006 00:57:33 +0000 (UTC) Ferris McCormick
<fmccor@gentoo.org> wrote:
| Well, the user did the work, too, and doesn't know that you did it
| (if I understand your case correctly).  So the user deserves as much
| credit as you do.

What? No, that's silly. The one who does the work gets the credit. If
you take all or a significant part of a user contribution, credit the
user. If you don't use the user contribution because their proposed fix
is lousy (a rather too common occurrence...), they just get credit for
reporting the issue.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Bugzilla etiquette suggestions

[Duncan]

Daniel Drake posted <43EFC3BD.7080902@gentoo.org>, excerpted below,  on
Sun, 12 Feb 2006 23:24:45 +0000:

> Henrik Brix Andersen wrote:
[Danial Drake wrote...]
>>> 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.
>>>
>>> This also applies for [...] 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?
> 
> Maybe not if you have already done the work. I was thinking more of the
> scenario, upstream does a release. You are on the mailing list so you
> know about the new version. You decide you'll bump it in portage
> tomorrow.
> 
> Overnight, someone files a request for a version bump. Maybe they attach
> a new ebuild or state that the existing one needs bumping.
> 
> Even though you knew about it, I was suggesting that you credit the user
> for filing the bug.

I don't recall where I read it, but it sounded reasonable to me then, and
deals with a possible issue, so I'll repeat it.  Somewhere I read
a recommendation for bump requests, addressed to users thinking of making
one, suggesting that they give the devs a week or two to do the bump
themselves, as they likely know about it because they are following the
list for that app, since they are the Gentoo maintainer for it, and just
need time to get something worked up and tested locally.  If after two
weeks, the bump isn't in portage, /then/ it's time to post the bug about
it.

Now, two weeks may be a bit long, but I'd say a week, anyway, of course
depending on the app (something big like gcc or gnome/kde bumps would be
different, but they are often in the tree even before the package is
publicly released and sources publicly available -- good job!).

I'd /not/ really wish to encourage version bump requests "overnight". 
That's  jumping the gun, and indeed, could encourage "first post" like
behavior.

What I'd do with such bugs is thank the user, but say next time, please
give me a few days, at least a week (or whatever a dev feels comfortable
with for that package, again, it'll vary) -- if it's /just/ a bump
request.  If I take over a week (or whatever), then maybe I need
reminding, so let me know!  OTOH, if the bug includes "I tried bumping the
last ebuild to use the new sources and it worked fine", or "... and it
broke at <whatever>", that's far more valuable than just a bump request,
and I'd treat it so.  (In fact, that sounds like possible AT/HT material,
maybe ultimately leading to a new dev, to me.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Daniel Drake]

Duncan wrote:
> I'd /not/ really wish to encourage version bump requests "overnight". 
> That's  jumping the gun, and indeed, could encourage "first post" like
> behavior.
> 
> What I'd do with such bugs is thank the user, but say next time, please
> give me a few days, at least a week (or whatever a dev feels comfortable
> with for that package, again, it'll vary) -- if it's /just/ a bump
> request.  

That is precisely what was being discussed on the private list which 
prompted me to finish off this post and publish it.

One point I was trying to make (as Mike and myself suggested on the 
private list) is that if you *do* receive a bump request too soon after 
release, then you ask the user nicely to wait 1 week (or whatever) after 
release in the future before filing bump requests.

You should *also* leave the bug open until the ebuild is in portage, 
then mark the bug as FIXED in the normal way, *and* you thank them by 
name in the commit message.

By showing them some basic respect for the fact they were trying to 
contribute, hopefully they will understand your position better and take 
up your advice.

You can argue that that *may* encourage "overnight" bump requests (which 
certainly isn't the intention), but in practice I think that won't 
happen too much if you treat the contributor in the proper manner.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Bugzilla etiquette suggestions

[Duncan]

Daniel Drake posted <43F0AFC7.2000407@gentoo.org>, excerpted below,  on
Mon, 13 Feb 2006 16:11:51 +0000:

> Duncan wrote:
>> I'd /not/ really wish to encourage version bump requests "overnight". 
>> That's  jumping the gun, and indeed, could encourage "first post" like
>> behavior.
>> 
> That is precisely what was being discussed on the private list which 
> prompted me to finish off this post and publish it.
> 
> One point I was trying to make (as Mike and myself suggested on the 
> private list) is that if you *do* receive a bump request too soon after 
> release, then you ask the user nicely to wait 1 week (or whatever) after 
> release in the future before filing bump requests.
> 
> You should *also* leave the bug open until the ebuild is in portage, 
> then mark the bug as FIXED in the normal way, *and* you thank them by 
> name in the commit message.
> 
> By showing them some basic respect for the fact they were trying to 
> contribute, hopefully they will understand your position better and take 
> up your advice.

WORKSFORME =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Mon, 2006-02-13 at 02:50 -0700, Duncan wrote:

> 
> What I'd do with such bugs is thank the user, but say next time, please
> give me a few days, at least a week (or whatever a dev feels comfortable
> with for that package, again, it'll vary) -- if it's /just/ a bump
> request.  If I take over a week (or whatever), then maybe I need
> reminding, so let me know!  OTOH, if the bug includes "I tried bumping the
> last ebuild to use the new sources and it worked fine", or "... and it
> broke at <whatever>", that's far more valuable than just a bump request,
> and I'd treat it so.  (In fact, that sounds like possible AT/HT material,
> maybe ultimately leading to a new dev, to me.)

bingo. a bug for bumping because their edges aren't bloody enough, bah,
it'll get done just as soon as i can, but not before then, probably in
the next week or so. now a version bump bug because it fixes an actual
BUG, ping me, that i'll avoid coffee breaks (actually...that's not a
good thing to do...) and sleep to get it in and working. I'm with this
Duncan on this one (and someone said the way i couldn't manage in my
other drafts :)

~mcummings

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On Monday 13 February 2006 00:24, Daniel Drake wrote:
> Maybe not if you have already done the work. I was thinking more of the
> scenario, upstream does a release. You are on the mailing list so you
> know about the new version. You decide you'll bump it in portage tomorrow.
>
> Overnight, someone files a request for a version bump. Maybe they attach
> a new ebuild or state that the existing one needs bumping.
This is a scenario quite good... if it wasn't that at least myself I see it 
rarely :)

Rarely because if I see a bump, I'm already starting testing it usually. 
Yesterday I finished amaroK's bump while I was eating dinner :P

In amaroK's case, anyway, there's no problem to know if it has relesed: 
upstream releases always in time, providing packagers with candidates to 
release, allowing to prepare stuff before actual release.. the release is 
also broadcasted in their homepage, on #amarok@freenode, on KDE-Apps, on 
kde-extra-gear mailing list, usually on Planet KDE, too....
Really, I don't need bugs to remember me to bump it.

Mostly the same for k3b.. it's released and then announced on kde-extra-gear, 
KDE-Apps, SourceForge, ..

I can be very thankful if someone would let me know when ALSA gets released as 
the upstream send mail to -announce once in a blue moon instead..

> That is a fair point, and if you can't afford to spend the time on it
> then I'm not complaining. However, there are situations where this can
> *save* you time.
I try to explain why I did some changes before committing or why I didn't use 
a given fix usually, I also try to provide documentation of what I do and why 
I do it that way (see maintainers' guides, that nobody else seems to want).
But really, if I get a bug for a thing to be fixed, I try to fix it right 
away... sometimes if I don't have time in that moment I leave a comment 
telling where or what to look for..not like there's always someone ready to 
fix :)
If I start thinking "this bug I'll fix later and provide just pointers to 
users, I'm sure I'm going to forget about it. I actually did that already :)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Daniel Drake]

Diego 'Flameeyes' Pettenò wrote:
> In amaroK's case, anyway, there's no problem to know if it has relesed: 
> upstream releases always in time, providing packagers with candidates to 
> release, allowing to prepare stuff before actual release.. the release is 
> also broadcasted in their homepage, on #amarok@freenode, on KDE-Apps, on 
> kde-extra-gear mailing list, usually on Planet KDE, too....
> Really, I don't need bugs to remember me to bump it.
> 
> Mostly the same for k3b.. it's released and then announced on kde-extra-gear, 
> KDE-Apps, SourceForge, ..
> 
> I can be very thankful if someone would let me know when ALSA gets released as 
> the upstream send mail to -announce once in a blue moon instead..

After contributing to the suggestions on -core I forgot to explain 
myself very clearly on this point.

I'm not suggesting a mechanism for handling or encouraging "0-day" bump 
requests - I'm giving a suggestion which I believe will help *reduce* 
those requests.

By leaving a nice comment (asking that they give us a little more room 
to breathe in future) *and* crediting the user, maybe they will take 
your advice to heart.

It's not up to the user to know how closely the maintainer tracks the 
upstream release (or even who the maintainer is in the first place), but 
in general we prefer to be left for a week or so before being notified 
via Gentoo bugzilla, right?

> I try to explain why I did some changes before committing or why I didn't use 
> a given fix usually, I also try to provide documentation of what I do and why 
> I do it that way (see maintainers' guides, that nobody else seems to want).

OK - thats a good compromise if you can't afford to spend the full 
amount of time guiding the user through it. I have never heard of your 
maintainer guides before but will check them out now.

> If I start thinking "this bug I'll fix later and provide just pointers to 
> users, I'm sure I'm going to forget about it. I actually did that already :)

Fair enough - I guess it depends on your workflow. Perhaps you could 
just try this for a couple of bugs: reassign them to yourself and leave 
the appropriate comments,then observing the users reaction. That way the 
bug is hard to lose since it is on your "My Bugs" list.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bugzilla etiquette suggestions

[Duncan]

Daniel Drake posted <43EFA485.4060709@gentoo.org>, excerpted below,  on
Sun, 12 Feb 2006 21:11:33 +0000:

> 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.

I like all the suggestions, but this one hits a particular sore spot, as I
had it happen to me, with I think my second Gentoo bug filing.  What made
things worse is that the filing was after my arch team had asked for
volunteers to perform specific tests (multilib-strict), and I had gone to
significant effort to do so, having builds die that would otherwise have
completed successfully.

As it happens, the bug /was/ valid, and was eventually resolved
(impressively quickly, I might add =8^) when I refiled it when the next
version came out.  I had something inadvised in my CFLAGS that
the developer had seized upon as an opportunity to mark the bug invalid
and get it out of his way, that in reality had nothing to do with the bug
(a 64-bit shared object installed to lib instead of lib64, independent of
CFLAGS, inadvised or not).

Calling the bug "invalid" can be taken personally as saying the opinion
and work that the user put into getting and filing the bug was  "invalid",
therefore, that the user shouldn't bother spending his time on Gentoo at
all, as they don't matter and they and there opinion are "invalid".

Consider this: INVALID is strong enough, under the wrong circumstances,
that it /could/ set an emotionally unstable user off, causing them to
commit suicide or something.  I /know/ it was deeply depressing here,
that first time, altho the effect on me would have been to simply push me
back to Mandrake and cause me to become another anti-Gentoo activist, as I
wasn't already suicidal. Some people /might/ be!  One never knows the
emotional state of someone filing a bug, so consider carefully the effect
INVALIDating the bug might possibly have on their entire life.  Would
/you/ want that on your conscience, that it had been /your/ action, the
marking of that one last bug they filed as INVALID, that finally tipped
them over? I know I wouldn't!

Obviously, I like the idea of NOTABUG better, or consider using WORKSFORME
or WONTFIX.  Those get the same general message across, without having the
implication of INVALIDating the user's bug, possibly/likely conveying the
message that they are not welcome as a Gentoo user, or worse yet to
someone already unstable, that their whole life is INVALID.

Thanks, Daniel!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Daniel Drake]

Duncan 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.
> 
> I like all the suggestions, but this one hits a particular sore spot, as I
> had it happen to me, with I think my second Gentoo bug filing.

I'm glad that you can relate to it - reassures me that I'm not pulling 
this out of thin air :)

 > What made
> things worse is that the filing was after my arch team had asked for
> volunteers to perform specific tests (multilib-strict), and I had gone to
> significant effort to do so, having builds die that would otherwise have
> completed successfully.
> 
> As it happens, the bug /was/ valid, and was eventually resolved

That's another issue which is worth thinking about. I'm just as bad at 
this myself - if I can close a bug report without doing any work (i.e. 
the case for most INVALID bugs) then it's almost like a small personal 
victory.

We should also try not to jump the gun so much in this kind of situation.

Thanks for the feedback, if bugzilla ever drives you to suicide I will 
be sure to file a bug report at the official Bugzilla bugzilla so that 
it can be corrected :)

Daniel

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Sun, 12 Feb 2006 15:53:37 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| Consider this: INVALID is strong enough, under the wrong
| circumstances, that it /could/ set an emotionally unstable user off,
| causing them to commit suicide or something.

Some people go around setting fire to embassies when they don't
understand a joke. Doesn't mean we should care about or cater to such
people.

INVALID doesn't necessarily mean it was wrong for the user to file the
bug. Heck, I've closed the occasional bug as INVALID (and sometimes have
even had the reporter do it) after massive debugging sessions and
discussions that go on for dozens of pages.

But... If INVALID is renamed, could we get a new GOAWAY resolution for
people who really deserve it?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Richard Fish]

On 2/13/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> But... If INVALID is renamed, could we get a new GOAWAY resolution for
> people who really deserve it?

I would tend to agree with this.  I myself was the 'victim' of an
aggressively worded INVALID resolution to a bug report I filed due to
my screwing up an upgrade to java 1.5.  Even though I didn't
particularly /like/ the response, I did learn that:

1. It was my own fault.
2. I needed to be really damn sure about future bug reports,
particularly when I unmask things!

So even if INVALID is watered down to be gentle to new (or easily
offended) users, you do occasionally need to smack abusers or people
who should know better (like me).

-Richard

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[lnxg33k]

> On 2/13/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> But... If INVALID is renamed, could we get a new GOAWAY resolution for
> people who really deserve it?

Like others here, I've also felt a bit stunned at an INVALID bug. Personally, I 
don't think anything needs to be renamed, but I would like to see a simple, 
short comment about why such a decision was made. This adds a bit more time for 
  people handling the bugs, but it saves confusion on the part of the person 
bugging, more time for an explanation to be given when/if the person asks why 
it was marked the way it was, and creating a whole host of new, specific tags.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Simon Stelling]

Duncan wrote:
> Consider this: INVALID is strong enough, under the wrong circumstances,
> that it /could/ set an emotionally unstable user off, causing them to
> commit suicide or something.  I /know/ it was deeply depressing here,
> that first time, altho the effect on me would have been to simply push me
> back to Mandrake and cause me to become another anti-Gentoo activist, as I
> wasn't already suicidal. Some people /might/ be!  One never knows the
> emotional state of someone filing a bug, so consider carefully the effect
> INVALIDating the bug might possibly have on their entire life.  Would
> /you/ want that on your conscience, that it had been /your/ action, the
> marking of that one last bug they filed as INVALID, that finally tipped
> them over? I know I wouldn't!

Are you being serious about this? I dont' find it particularly funny in case
it's a joke. In case it's not, i find it ridiculous. If a person is that
emotionally unstable that he'd commit suicide because of an INVALID resolution,
he'd probably commit suicide everytime only the slightest negative event occurs
too. I really feel sorry for those people who are depressive, but I wouldn't
feel guilty because I closed a bug as INVALID instead of WORKSFORME.

> Obviously, I like the idea of NOTABUG better, or consider using WORKSFORME
> or WONTFIX.  Those get the same general message across, without having the
> implication of INVALIDating the user's bug, possibly/likely conveying the
> message that they are not welcome as a Gentoo user, or worse yet to
> someone already unstable, that their whole life is INVALID.

NOTABUG sounds good, but as Ciaran said, we need another replacement for those
bugs who really deserve it. If a user sticks -fvisibility=hidden into his CFLAGS
(instead of CXXFLAGS), PLEASEGOAWAYKTHXBYE would be much more appropriate.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <blubb@gentoo.org>
wrote:
| Are you being serious about this?

Sadly, even if he is, there're enough people around here that're taking
that kind of thought seriously (see, for example, my sarcastic post on
the 0day -core thread that so many people took as genuine)...

| NOTABUG sounds good, but as Ciaran said, we need another replacement
| for those bugs who really deserve it. If a user sticks
| -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS),
| PLEASEGOAWAYKTHXBYE would be much more appropriate.

They also deserve it if they stick it in their CXXFLAGS...

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Patrick McLean]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <blubb@gentoo.org>
> wrote:
> | Are you being serious about this?
> 
> Sadly, even if he is, there're enough people around here that're taking
> that kind of thought seriously (see, for example, my sarcastic post on
> the 0day -core thread that so many people took as genuine)...
> 
> | NOTABUG sounds good, but as Ciaran said, we need another replacement
> | for those bugs who really deserve it. If a user sticks
> | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS),
> | PLEASEGOAWAYKTHXBYE would be much more appropriate.
> 
> They also deserve it if they stick it in their CXXFLAGS...
> 

How about RICER or RICERFLAGS :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD8NdgWt/XSf2CZdkRAlUQAJ99NlKvRVK3zvqX+R8iZH07LvTpoACfS+sW
EtylhPAKUZ9qaxm6Jv3o1gk=
=UDkC
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Marien Zwart]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

On Mon, Feb 13, 2006 at 02:00:48PM -0500, Patrick McLean wrote:
> 
> How about RICER or RICERFLAGS :)

+1. "RESOLVED RICER" has such a nice ring to it :)

-- 
Marien.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Grobian]

On 13-02-2006 18:49:18 +0000, Ciaran McCreesh wrote:
> On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <blubb@gentoo.org>
> wrote:
> | NOTABUG sounds good, but as Ciaran said, we need another replacement
> | for those bugs who really deserve it. If a user sticks
> | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS),
> | PLEASEGOAWAYKTHXBYE would be much more appropriate.
> 
> They also deserve it if they stick it in their CXXFLAGS...

I don't agree on such solution, because getting rid of personal
frustrations of a developer should *not* be supported by Gentoo's
Bugzilla.  These kind of emotions give a rather weak signal, and do not
really show any kind of profesionalism IMHO.

If these frustrations get so apparent that they require a solution flag
in Bugzilla for a developer, then it might be a better solution to just
leave the bugzilla work to someone else and try to work a bit more away
from the users for a while.  It is a well known issue that people who
have to work with others get frustrated (e.g. call-center employees).


-- 
Fabian Groffen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Mon, 13 Feb 2006 20:07:51 +0100 Grobian <grobian@gentoo.org> wrote:
| If these frustrations get so apparent that they require a solution
| flag in Bugzilla for a developer, then it might be a better solution
| to just leave the bugzilla work to someone else and try to work a bit
| more away from the users for a while.

Most of us don't have the luxury of being able to ignore real users...

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Grobian]

On 13-02-2006 19:21:57 +0000, Ciaran McCreesh wrote:
> On Mon, 13 Feb 2006 20:07:51 +0100 Grobian <grobian@gentoo.org> wrote:
> | If these frustrations get so apparent that they require a solution
> | flag in Bugzilla for a developer, then it might be a better solution
> | to just leave the bugzilla work to someone else and try to work a bit
> | more away from the users for a while.
> 
> Most of us don't have the luxury of being able to ignore real users...

Maybe that has to change then?  Like getting more bug wranglers that
also handle canned responses as a first-line helpdesk?


-- 
Fabian Groffen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Monday 13 February 2006 20:29, Grobian wrote:
> Maybe that has to change then?  Like getting more bug wranglers that
> also handle canned responses as a first-line helpdesk?

Wrangle bugs a few months and you'll see how hard it can be to stay friendly 
sometimes... And no, bugzilla is not a helpdesk. We have mailing lists and 
forums.g.o for this.

btw.: I think the idea to give someone credit for requesting a version bump is 
pretty much ridiculous. There're helpful requests/bug reports, where credit 
is due, but the usual case of a request for a new version isn't.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Grobian]

On 13-02-2006 21:02:28 +0100, Carsten Lohrke wrote:
> On Monday 13 February 2006 20:29, Grobian wrote:
> > Maybe that has to change then?  Like getting more bug wranglers that
> > also handle canned responses as a first-line helpdesk?
> 
> Wrangle bugs a few months and you'll see how hard it can be to stay friendly 
> sometimes...

That's what I said two posts ago.


-- 
Fabian Groffen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

On Monday 13 February 2006 19:49, Ciaran McCreesh wrote:
> They also deserve it if they stick it in their CXXFLAGS...
In that case even more, as it actually does something: break stuff.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Bugzilla etiquette suggestions

[Duncan]

Simon Stelling posted <43F0D24A.6060409@gentoo.org>, excerpted below,  on
Mon, 13 Feb 2006 19:39:06 +0100:

> Duncan wrote:
>> Consider this: INVALID is strong enough, under the wrong circumstances,
>> that it /could/ set an emotionally unstable user off, causing them to
>> commit suicide or something.
> 
> Are you being serious about this? I dont' find it particularly funny in
> case it's a joke. In case it's not, i find it ridiculous. If a person is
> that emotionally unstable that he'd commit suicide because of an INVALID
> resolution, he'd probably commit suicide everytime only the slightest
> negative event occurs too. I really feel sorry for those people who are
> depressive, but I wouldn't feel guilty because I closed a bug as INVALID
> instead of WORKSFORME.

Perhaps you've never been suicidal.  It's no joke.

There was a single event in my life, over 20 years ago, where I was very
temporarily (like a day) suicidal.  Having experienced that, yes, I'm
/very/ serious, altho I understand your skepticism as well, particularly
if you've been lucky enough to have never dealt with the issue personally.

The details are personal, inappropriate, and unnecessary to the
discussion, but the very general situation was this:  I was already sick
and thus out of normal physical/mental/emotional balance as it was, when
someone made a comment that due to that unbalance, I took personally and
blew /way/ out of proportion.  Luckily, I didn't act on the impulse and as
soon as I got some sleep and recovered at least a modicum of physical
health, the whole thing looked as ridiculous as it actually was.  Having
faced those particular personal demons once, I've never had to face them
again and don't expect I ever will.

The point is, the person that made that remark had no idea the effect it
had on me -- and what the result might have been.  However, having gone
thru that once, even 20 years ago, I still remember the despondency, the
utter lack of hope, the distorted world-view that a day later seemed so
ridiculous.

The point is, to a person in that shape, even something seemingly tiny, to
someone unaffected by that distortion field, can be enough to push someone
over.

The point is, one never knows, particularly over the net dealing with a
person you've never met in real life and haven't interacted with on a
regular basis even on the net, what sort of weird personal stuff they
might be dealing with at the particular time you're interacting.

The point is, yes, it's /exactly/ "little" stuff like that "INVALID", that
if it hits at the wrong juncture in someone's  life journey, just /might/
cause them to end it.

Getting INVALID stamped across a first or second bug posting /can/ be
depressing, I /know/!  For any /normal/ person, even at its worst, it'll
be no worse than the dozens of other little irritations one experiences on
a daily basis.  However, a similar assumption on the part of that guy all
those many years ago came very close to having fatal consequences. Yes,
that /is/ serious!

I don't expect those who've never faced suicide as what appeared to be a
reasonable choice to even begin to understand.  Just be aware that it
/can/ happen, and consider what your response would be if a final note was
found that named a comment you made as the deciding factor.  It /can/
happen.  Unfortunately, a lot of folks end up asking themselves serious
questions about their last interactions with someone they were talking to
only yesterday, and how whatever they said must have looked to the poor
guy considering the act, every day.

Luckily, that's the only time it it's ever even looked like an option, to
me.  However, that once was enough.  Obviously, it has had some lasting
effects on how I choose to deal with folks, to this day.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Bugzilla etiquette suggestions

[Stephen P. Becker]

> The point is...
> 
> The point is...
> 
> The point is...
> 
> The point is...

The point is, you need to stop polluting this list with completely
off-topic sub-rants which have nothing to do with gentoo development.
You do a very good job at killing useful threads with your essays on
world peace.

-Steve

P.S. Overuse of annoying /emphasis/ makes my eyes bleed.  Please stop.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Bugzilla etiquette suggestions

[Duncan]

Stephen P. Becker posted <43F1D8A7.3090809@gentoo.org>, excerpted below, 
on Tue, 14 Feb 2006 08:18:31 -0500:

> The point is, you need to stop polluting this list with completely
> off-topic sub-rants which have nothing to do with gentoo development.
> You do a very good job at killing useful threads with your essays on
> world peace.

It's not entirely off topic, as it pertains to dev/user relations.  Note
that I didn't go into detail originally, until asked to clarify, which I
did.  That's not off topic, that's supplying logical support for an
on-topic answer to an on-topic, even "useful", question.  You don't have
to agree with my particular viewpoint on "world peace", to see how my
answer related to the topic at hand.

In any case, it's certainly more on topic than references to goats and the
like.  Yes, I understand the joking and etc in the context of welcoming a
new dev and yes, I consider it reasonably appropriate, precisely on topic
or not. That's not the point. It can't however be reasonably argued that
such comments are any closer to on topic than mine are, yet the same folks
that complain about my comments don't emit a peep when these farther from
topic comments come up.  Where's the consistency?

Having no rule that can be applied to all cases with consistent results,
how am I to know when I'm breaking the rule?  I can't.  It's therefore
impossible to comply, because the rule appears to be arbitrary, with no
consistent application possible.  If a consistent rule exists, make it
known, and perhaps the results will be more agreeable.

Also... how can I kill a useful thread of tens or hundreds of posts from
multiple posters, with a single "essay on world peace"?  Am I making the
posting choices for the other participants?  Hardly.  How then can it be
possible for me to kill the thread, when it's always possible to ignore my
"essay" and the resulting subthread, if desired, and continue posting away
on the more "useful" subthreads, as if I'd never posted in the first
place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Marien Zwart]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On Sun, Feb 12, 2006 at 09:11:33PM +0000, Daniel Drake wrote:
> I wrote most of this a while ago but didn't get round to finishing it. 
> This seems appropriate at this time, so here it is :)
> 
> Here are some small *suggestions* for how I think we can motivate users 
> on Bugzilla to contribute more, and to contribute more often. I'm not 
> suggesting this be enforced as policy, but it would be nice to see other 
> developers giving this some thought. I'm far from perfect here, but I am 
> working on sticking to my own suggestions more and more.

Agree with and try to follow most of this myself, but I'm hesitant
about:

> 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.

I think this is too much effort, especially for small corrections. I
tend to fix them myself, commit with a message like "...based on an
ebuild from ... (bug #....)" and comment on the bug like "Committed
with minor changes". It would probably be a good thing if I went into
a bit more detail about what the "minor changes" were and why I made
them, I guess :)

<snip>
> 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).

I am extremely bad at the "not sounding generic" bit... :(


-- 
Marien.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Daniel Drake]

Marien Zwart wrote:
> I think this is too much effort, especially for small corrections. I
> tend to fix them myself, commit with a message like "...based on an
> ebuild from ... (bug #....)" and comment on the bug like "Committed
> with minor changes". It would probably be a good thing if I went into
> a bit more detail about what the "minor changes" were and why I made
> them, I guess :)

Perhaps you could try this a couple of times when the opportunity next 
arises. If done well, you only need to type a sentence or two if it is 
just minor issues that need correcting. Also bookmark Ciaran's nice mini 
FAQ which covers lots of common mistakes:

http://dev.gentoo.org/~ciaranm/docs/mw-faq

It may feel a little harsh to give someone a canned response just by 
pasting a URL in the comment field, but curious readers will find his 
faq.txt which explains nicely that we aren't evil/lazy, we just have a 
lot of work to do. Thanks Ciaran!

I guess the only other downside to this approach is that it delays the 
fix - instead of fixing it right then, you have to wait for another 
round of communication to complete before closing the bug. That is 
undesirable for people with busy schedules.

Thanks for the feedback.
Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Sun, 12 Feb 2006 23:32:39 +0000 Daniel Drake <dsd@gentoo.org> wrote:
| It may feel a little harsh to give someone a canned response just by 
| pasting a URL in the comment field, but curious readers will find his 
| faq.txt which explains nicely that we aren't evil/lazy, we just have
| a lot of work to do. Thanks Ciaran!

And some users throw a hissy fit when given a detailed link to a canned
response and demand that in future they get personally typed out
explanations rather than a link to a detailed pre-written resource that
goes into far more depth than anyone could possibly manage in a
personalised response. Hence why I no longer spend much time helping in
maintainer-wanted bugs unless a submitter specifically asks me to take
a look at something for them -- all it takes is for one user to escalate
their hissy fit to a devrel bug...

Oh, and don't think that this behaviour is limited to end users. Sadly
the same thing has been observed in certain Gentoo developers.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

Ciaran McCreesh wrote:
> On Sun, 12 Feb 2006 23:32:39 +0000 Daniel Drake <dsd@gentoo.org> wrote:
> | It may feel a little harsh to give someone a canned response just by 
> | pasting a URL in the comment field, but curious readers will find his 
> | faq.txt which explains nicely that we aren't evil/lazy, we just have
> | a lot of work to do. Thanks Ciaran!
> 
> And some users throw a hissy fit when given a detailed link to a canned
> response and demand that in future they get personally typed out
> explanations rather than a link to a detailed pre-written resource that
> goes into far more depth than anyone could possibly manage in a
> personalised response. Hence why I no longer spend much time helping in
> maintainer-wanted bugs unless a submitter specifically asks me to take
> a look at something for them -- all it takes is for one user to escalate
> their hissy fit to a devrel bug...
> 
> Oh, and don't think that this behaviour is limited to end users. Sadly
> the same thing has been observed in certain Gentoo developers.

Perhaps pasting the response into the bug itself would prevent most of
this. It just takes a few seconds, but feels more personal.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Ned Ludd]

Thank you for taking the time to put preXX doc this mail together.

I find it personally inspiring and a reminder to watch how I/we handle 
bugs which is often easy to overlook.




On Sun, 2006-02-12 at 21:11 +0000, Daniel Drake wrote:
> I wrote most of this a while ago but didn't get round to finishing it. 
> This seems appropriate at this time, so here it is :)
> 
> Here are some small *suggestions* for how I think we can motivate users 
> on Bugzilla to contribute more, and to contribute more often. I'm not 
> suggesting this be enforced as policy, but it would be nice to see other 
> developers giving this some thought. I'm far from perfect here, but I am 
> working on sticking to my own suggestions more and more.
> 
> Remember that Bugzilla is the only way we communicate with most of our 
> external contributors so it is important to make them feel appreciated 
> and give them a good impression of the Gentoo developer community.
> 
> 1. Don't bitch at contributors
> 
> Even if they did something totally wrong, violated all known policies, 
> and you are *sure* they just filed the bug to annoy you, don't write 
> aggressive sounding responses.
> 
> Reasons being:
> - You'll reduce the chances they'll think about contributing again in 
> the future
> - They probably won't listen to a word you say, yet will feel the need 
> to respond
> - Bugzilla is a public medium, and other potential contributors (who 
> maybe wouldn't have made such 'obvious' mistakes) will be put off when 
> reading the aggressive dialog.
> (I'm not suggesting that you send abuse privately instead!)
> - Like we aren't paid to fix bugs, the users aren't paid to file them: 
> at the end of the day, someone went out of his/her way to file the bug, 
> to try and help.
> 
> 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.
> 
> Marking bugs as duplicates is also dodgy ground: Comments like "Please 
> search" can easily be taken the wrong way. I'm probably asking too much 
> for people to spend lots of time thinking up appreciative duplicate 
> messages, however...
> 
> 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.
> 
> This also applies to contributors who you know well, contributors who 
> you have named 9999 times before, and other Gentoo developers too.
> 
> 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.
> 
> 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).
> 
> 6. Don't forget about email
> 
> As a Gentoo developer, you have been automatically granted the ability 
> to sound important and make others feel important too.
> 
> When Seemant mailed me over 2 years ago, I was a relative idiot and was 
> a new Gentoo user at that time. It felt great to receive a complimentary 
> email from a well-known and respected Gentoo developer, and that email 
> eventually led to me becoming a developer myself (amongst other things!).
> 
> I've had the same kind of effect on people since then, for example, I 
> sent a very quick "thanks" mail to the guy who authored the wordpress 
> theme I run on my weblog, and he was overjoyed that I was using it - he 
> happened to be a Gentoo user who already read my blog via the Planet site.
> 
> There probably aren't many situations where you would email a user who 
> communicates with you on bugzilla. But don't forget about this nice 
> ability that we have :)
> 
> 
> 
> That's all I can think of for now. I'd certainly be interested to hear 
> any comments on the above and similar suggestions that others may have.
> 
> Daniel
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Shyam Mani]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Ned Ludd wrote:

> Thank you for taking the time to put preXX doc this mail together.
> I find it personally inspiring and a reminder to watch how I/we handle 
> bugs which is often easy to overlook.

Thanks for saying what I wanted to say Ned, I totally agree with you.

Regards,

-- 
Shyam Mani | <fox2mike@gentoo.org>
docs-team  | http://gdp.gentoo.org
GPG Key    | 0xFDD0E345


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bugzilla etiquette suggestions

[Shyam Mani]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

Daniel Drake wrote:

> Maybe we should consider alternatives. I quite like the NOTABUG
> resolution they have on the GNOME bugzilla.

I think this is a good idea. Shouldn't be too difficult to put this in /
replace INVALID with NOTABUG I guess.

Regards,

-- 
Shyam Mani | <fox2mike@gentoo.org>
docs-team  | http://gdp.gentoo.org
GPG Key    | 0xFDD0E345


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]