From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F8P3i-0000sb-Rj for garchives@archives.gentoo.org; Sun, 12 Feb 2006 21:47:07 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1CLjpCQ032208; Sun, 12 Feb 2006 21:45:51 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1CLhgW9029662 for ; Sun, 12 Feb 2006 21:43:43 GMT Received: from 83.72.33.139.ip.tele2adsl.dk ([83.72.33.139] helo=osgiliath.brixandersen.dk) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1F8P0Q-0000bl-65 for gentoo-dev@lists.gentoo.org; Sun, 12 Feb 2006 21:43:42 +0000 Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id BB47550E70; Sun, 12 Feb 2006 22:43:40 +0100 (CET) Date: Sun, 12 Feb 2006 22:43:40 +0100 From: Henrik Brix Andersen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Bugzilla etiquette suggestions Message-ID: <20060212214340.GK30002@osgiliath.brixandersen.dk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <43EFA485.4060709@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: <43EFA485.4060709@gentoo.org> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 X-Archives-Salt: 7deb96fa-f9d6-4212-8b12-ac4f87f0070a X-Archives-Hash: 5abf51b9c8d7efeb772018cba4a7753c --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Feb 12, 2006 at 09:11:33PM +0000, Daniel Drake wrote: > 2. Be careful with INVALID resolutions >=20 > The term invalid _is_ harsh in bugzilla context, so make sure you write= =20 > a quick thankful-sounding comment to go with it. >=20 > Maybe we should consider alternatives. I quite like the NOTABUG=20 > 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 >=20 > If you commit something in response to a bug report that has been filed,= =20 > always thank the user by full name (and bug number) in the ChangeLog and= =20 > commit message. >=20 > Do the above even if you already knew about the bug (i.e. you would have= =20 > committed the same fix even if the user hadn't alerted you). >=20 > This also applies for ebuild requests, ebuild submissions, and version=20 > bump requests/submissions. Might sound pointless for 'trivial'=20 > reports/requests but it is important to credit the user if they have=20 > 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=20 > 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 >=20 > If a user contributes a patch/ebuild which is slightly wrong, and the=20 > issue is non-critical, don't immediately correct it on their behalf and= =20 > commit it to get the bug out of the way. > > Instead, provide an explanation of their mistake and give the user a day= =20 > or two to correct it and attach an updated version. This has the bonuses= =20 > that the user definately won't repeat that mistake in future=20 > contributions, and they will have the nice feeling of full credit for=20 > the contribution after you name them in the ChangeLog :) > > If they don't respond in that time, make the correction yourself and=20 > 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 >=20 > When marking a bug as FIXED, I often forget that the user has tested 4=20 > kernel versions, moved their network card over to another computer,=20 > filed an identical bug report upstream, tested the solution, and=20 > reported back to me. > > I think a short note of thanks in the bugzilla comment can go a long way= =20 > (suggestion: thank them for something in particular so that it doesn't=20 > 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 --=20 Henrik Brix Andersen Gentoo Metadistribution | Mobile computing herd --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: GnuPG signed iD8DBQFD76wMv+Q4flTiePgRAv9+AKDIEKmrrgBc9Z5Pse4dd+h/lGCKtACePBnQ MS0jbFb9ZRHhoJEEsVATP14= =ImzT -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v-- -- gentoo-dev@gentoo.org mailing list