Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.175 as permitted sender)
	client-ip=209.85.161.175; envelope-from=nanotube@gmail.com;
	helo=mail-gg0-f175.google.com; 
Message-ID: <50003CDA.60205@gmail.com>
Date: Fri, 13 Jul 2012 11:20:58 -0400
From: Daniel F <nanotube@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com>
	<CAAS2fgRd0gqrxXs4Le6nydYBaG7EO=T7FrtX6QZpg3aJtAxSvg@mail.gmail.com>
	<1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
	<CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
	<1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com>
	<CANEZrP1vwDubXrY3eoq4P4SAN=GK06iVaVx4pMWZKmBwQc9awg@mail.gmail.com>
	<4FFB5A7E.7020604@justmoon.de>
	<CANEZrP3Y3nvRwiPw66bDhp01JnE-zVurw5MnxPzR-bi5H8h4Aw@mail.gmail.com>
	<4FFB9537.8040909@justmoon.de> <4FFB9707.9020307@gmail.com>
	<CAAS2fgT10nf=8TJxYrT4WBNdYUiSU7qQNDTjjbTSuMktn2QVpw@mail.gmail.com>
	<4FFBF1DF.8070203@justmoon.de>
In-Reply-To: <4FFBF1DF.8070203@justmoon.de>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig8C4825FD632DD8EDFC5F8A37"
Subject: Re: [Bitcoin-development] Random order for clients page
Precedence: list

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8C4825FD632DD8EDFC5F8A37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This discussion is quite bikesheddy, but (or thus? :) ) I will put in my
2c.

The main thing to think about, I think, is "what would be best for the
users". To that end, I suggest the following:

* I do think a page on bitcoin.org listing relatively major, and
relatively vetted, clients is a good idea. Removing it completely and
relegating it to a wiki page, which is likely to contain all sorts of
marginal crufty clients, would likely be a disservice to the users.

* Randomized order is likely also a disservice to the users. We should
list clients in order of "goodness", as determined by whoever(s) we
decide to put in charge of the page. This "goodness" should likely to be
some kind of weighted average of features, security, goodness for
bitcoin network, etc. [1]

** If randomized order is after all chosen, it should be done in
javascript client-side, rather than doing daily page reorgs. If people
without JS don't see random, it's not material at all.

* Prose vs. feature matrix: both have their good and bad points, as
discussed upthread. I think the users will be best served by a
combination of both:

** Prose descriptions of clients should deliberately include negative
points, not just let the user infer them by lack of corresponding
positive mention. (e.g. "This client has fast startup time. That means
you're completely trusting the server operator with your money.") This
task is left up to the person(s) in charge.

** A feature matrix, with carefully chosen and /well defined/
categories, /in addition to prose/ would likely also be of service to
the users. That could be left to the wiki though. The current wiki
clients page seems to be having a good go at it.[2]

** If we are targeting people who "don't know what they're doing", it
may be a good idea to have a 'decision assistant' type setup, where
users are asked several questions and are recommended clients based on
these answers. (This could be done in a static way by having a matrix of
questions.)


Finally - I'd say we're spending disproportionate developer resources on
this question, and if it were completely up to me, I'd resolve this
situation in the following quick-and-painless way: leave page as is, add
negative points to prose, link to wiki clients list. Estimated time to
completion: 1 hour (to think through which negative points to add).


[1] Meehl, 1954, clinical versus statistical prediction... (see also
Grove and Meehl, 1996; Sawyer, 1966) (and yes, despite the age of some
of this research, the conclusions have been surprisingly robust and
timeproof.)
[2] https://en.bitcoin.it/w/index.php?title=3DClients&oldid=3D28615

-nanotube


--------------enig8C4825FD632DD8EDFC5F8A37
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAAPN4ACgkQ5/k4vslVlLK2xgCfRMnbYpEPPasz0EyUIJQbfyl6
KbAAn3g2r8DN5auG0SuOA64uLeUYrcmU
=l8rU
-----END PGP SIGNATURE-----

--------------enig8C4825FD632DD8EDFC5F8A37--