Re: [gentoo-dev] Bugzilla etiquette suggestions
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 | [EMAIL PROTECTED] docs-team | http://gdp.gentoo.org GPG Key| 0xFDD0E345 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
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 | [EMAIL PROTECTED] docs-team | http://gdp.gentoo.org GPG Key| 0xFDD0E345 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 00:57:33 + (UTC) Ferris McCormick [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, 12 Feb 2006 23:32:39 + Daniel Drake [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
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 [EMAIL PROTECTED], 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 pgpaCy0O4P7CY.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
Ciaran McCreesh wrote: On Sun, 12 Feb 2006 23:32:39 + Daniel Drake [EMAIL PROTECTED] 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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Bugzilla etiquette suggestions
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 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
Hi, On Sun, Feb 12, 2006 at 09:11:33PM +, 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 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
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, Feb 12, 2006 at 09:11:33PM +, 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. pgp8ekbbuVh0A.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
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
-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) [EMAIL PROTECTED] 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
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 +, 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 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
