public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gary Rowe <g.rowe@froot•co.uk>
To: Alan Reiner <etotheipi@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
Date: Mon, 9 Jul 2012 21:13:04 +0100	[thread overview]
Message-ID: <CAKm8k+39h=SdKg8dd70UhOrN9+kRQRvsh93jksQB3T=fMZW6qQ@mail.gmail.com> (raw)
In-Reply-To: <CALf2ePyzxF6D8yiOm7Lk1X4u4WO3XRHtKXBwaELA0zx8i7u0mg@mail.gmail.com>

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

Although I can only speak for my involvement with MultiBit, the idea of a
randomised client page seems wrong to me, for the reasons given by Alan
earlier.

Equally, in order to further the idea that Bitcoin is more than the
reference client, it is appropriate that other clients are acknowledged and
promoted. Bitcoin.org has by far the most traffic and by directing people
to other clients that may be more suitable to their needs the user
experience is improved considerably. After all, not everyone wants a 2.5Gb+
download before starting out on their Bitcoin adventure.

If the reference client was the best of all possible worlds then there
would be no need for the alternative clients.

On 9 July 2012 20:14, Alan Reiner <etotheipi@gmail•com> wrote:

> I was originaly for the idea of randomization.  Because it is the most
> "fair", but "fair" is a relative term.  It's fair for client developers who
> argue over whose client should be first, and whose is better for various
> purposes.   But it's not fair for users, to have an inconsistent page, that
> sometimes recommends less-developed solutions, or doesn't show what's best
> *for the users in the community*.
>
> I think the premise of having a page that is "fair for developers" is its
> downfall.  Once we agree things have to be fair, we must agree on what fair
> means, and then we must accept 30 new recently-started projects that barely
> squeak by the requirements for being on the page, despite having
> substantial issues/bugs.  The premise of being fair is the downfall here.
>
> This *has* to be a subjective list.   Someone who is trusted to
> understand what is good for users, and who also has familiarity with the
> programs, should be the one to decide.  People can try to provide input,
> and make them aware of stuff they didn't know.  But it should be *that
> person's* decision, and if it's not "fair" in your world, too bad.  At
> least we won't spend the next 3 years arguing on the mailing list about how
> to compare programs that are all great in many different dimensions, and
> failing in the others.
>
> If it's going to go on the main page, give someone the responsibility to
> come up with "what's best for the users of Bitcoin.org", however they
> decide to interpret it, and save our breath arguing over more important
> things.
>
> -Alan
>
>
>
> On Mon, Jul 9, 2012 at 2:57 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:
>
>> On Mon, Jul 9, 2012 at 2:54 PM, Jim <jim618@fastmail•co.uk> wrote:
>> > RE: The position randomisation - I have to admit I was secretly pleased
>> > with the original layout, as MultiBit just happened to have the "eye
>> > candy" position of "top and centre".  It is only fair to have them
>> > switch around.
>>
>> This ordering wasn't accidental.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5614 bytes --]

  reply	other threads:[~2012-07-09 20:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 18:54 Jim
2012-07-09 18:57 ` Gregory Maxwell
2012-07-09 19:14   ` Alan Reiner
2012-07-09 20:13     ` Gary Rowe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-07-09 15:54 Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09   ` Amir Taaki
2012-07-09 16:39     ` Stefan Thomas
2012-07-09 16:55       ` Harald Schilly
2012-07-09 17:21         ` Luke-Jr
2012-07-09 17:46     ` Gregory Maxwell
2012-07-09 18:03       ` Alan Reiner
2012-07-09 18:29         ` thomasV1
2012-07-09 18:18       ` Amir Taaki
2012-07-09 18:30         ` Mike Hearn
2012-07-09 22:26           ` Stefan Thomas
2012-07-09 22:37             ` Mike Hearn
2012-07-10  2:36               ` Stefan Thomas
2012-07-10  2:44                 ` Alan Reiner
2012-07-10  3:05                   ` Gregory Maxwell
2012-07-10  7:12                     ` Wladimir
2012-07-10  9:11                     ` Stefan Thomas
2012-07-13 15:20                       ` Daniel F
2012-07-09 18:48         ` Gregory Maxwell
2012-07-09 20:44   ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24   ` Amir Taaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKm8k+39h=SdKg8dd70UhOrN9+kRQRvsh93jksQB3T=fMZW6qQ@mail.gmail.com' \
    --to=g.rowe@froot$(echo .)co.uk \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=etotheipi@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox