From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qlsy1-00033r-IB for bitcoin-development@lists.sourceforge.net; Wed, 27 Jul 2011 01:31:21 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.43 as permitted sender) client-ip=209.85.210.43; envelope-from=gavinandresen@gmail.com; helo=mail-pz0-f43.google.com; Received: from mail-pz0-f43.google.com ([209.85.210.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qlsy0-0003Nl-L9 for bitcoin-development@lists.sourceforge.net; Wed, 27 Jul 2011 01:31:21 +0000 Received: by pzk1 with SMTP id 1so1859785pzk.30 for ; Tue, 26 Jul 2011 18:31:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.228 with SMTP id h4mr5996225pbm.9.1311730274734; Tue, 26 Jul 2011 18:31:14 -0700 (PDT) Received: by 10.142.163.9 with HTTP; Tue, 26 Jul 2011 18:31:14 -0700 (PDT) Date: Wed, 27 Jul 2011 11:31:14 +1000 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=bcaec520f4b91112db04a903011e X-Spam-Score: -0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qlsy0-0003Nl-L9 Subject: [Bitcoin-development] Seeking advice: Encouraging bug-fixing over new features X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 01:31:21 -0000 --bcaec520f4b91112db04a903011e Content-Type: text/plain; charset=ISO-8859-1 Anybody have advice on how to encourage more bug-fixing and testing of existing functionality instead of yet-more-features? When I get back home from here in Australia I plan on trying to lead-by-example by starting to tackle the huge backlog of reported bugs, but I'd like to know if anybody has seen other open source projects successfully get people to fix bugs instead of constantly adding features. Would policies like "that spiffy new feature you want won't be considered until you've helped close some open bugs" be effective (or would it just encourage people to create shill accounts to open trivial-to-fix issues)? If this was your run-of-the-mill open source project I would be much more lackadaisical about letting in new features... but when people lose money because bugs slip through (and several people HAVE recently lost money because of bugs slipping through) we obviously have a pretty big problem just making sure that the features we have now work properly. (Thanks VERY much to those of you have HAVE been helping test and have been submitting bug fixes; I don't mean to imply that everybody has been feature-happy, just that it seems like a lot of potential bitcoin contributors start out by submitting a nifty new feature that sure would be nice to have if we weren't so busy trying to make sure the features we already have work properly all the time). -- -- Gavin Andresen --bcaec520f4b91112db04a903011e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anybody have advice on how to encourage more bug-fixing and testing of exis= ting functionality instead of yet-more-features?

When I = get back home from here in Australia I plan on trying to lead-by-example by= starting to tackle the huge backlog of reported bugs, but I'd like to = know if anybody has seen other open source projects successfully get people= to fix bugs instead of constantly adding features. Would policies like &qu= ot;that spiffy new feature you want won't be considered until you'v= e helped close some open bugs" be effective (or would it just encourag= e people to create shill accounts to open trivial-to-fix issues)?

If this was your run-of-the-mill open source project I = would be much more=A0lackadaisical=A0about letting in new features... but w= hen people lose money because bugs slip through (and several people HAVE re= cently lost money because of bugs slipping through) we obviously have a pre= tty big problem just making sure that the features we have now work properl= y.

(Thanks VERY much to those of you have HAVE been helpin= g test and have been submitting bug fixes; I don't mean to imply that e= verybody has been feature-happy, just that it seems like a lot of potential= bitcoin contributors start out by submitting a nifty new feature that sure= would be nice to have if we weren't so busy trying to make sure the fe= atures we already have work properly all the time).

--
--
Gavin Andresen

--bcaec520f4b91112db04a903011e--