public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stefan Thomas <moon@justmoon•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
Date: Tue, 10 Jul 2012 00:26:06 +0200	[thread overview]
Message-ID: <4FFB5A7E.7020604@justmoon.de> (raw)
In-Reply-To: <CANEZrP1vwDubXrY3eoq4P4SAN=GK06iVaVx4pMWZKmBwQc9awg@mail.gmail.com>


> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective.

I strongly agree, but this is *why* I suggested moving it to the wiki. I
recently had to choose an XMPP client and I looked on xmpp.org - after a
frustrating experience with their listing [1], I went to Wikipedia who
have an decent feature-based matrix [2].

(There may be better examples, but I'm using this one, because this
actually did happen.)

This is just anecdotal, but there are some reasons why wikis tend to do
a better for this kind of thing is because they are:

- more up-to-date (anyone can update them)
- more in touch with users:
  -> Users can edit the page and add a column to a feature matrix for
example).
  -> The editing discussions include users. I guarantee there are more
Bitcoin end users with a wiki account than a Github account.
-  immediately recognizable as a wiki (thanks to Mediawiki/Wikipedia.)
As such many users will correctly treat and interpret the information
presented as community-generated and fallible.

So they are more user-oriented in the sense that they will be influenced
by a diverse set of backgrounds and views vs. a Github based page which
will be dominated by developers. If you want to see "the result of
internal politics", the current client page is a good example. We
couldn't agree on the columns for a feature matrix, so now we just have
walls of text. Some of the options that are de-facto the most popular
with users like BlockChain.info or just using your MtGox account are not
mentioned at all. When analyzing client security, Greg discussed
counterparty risks but ignored other risk factors like default backup
behavior and the usability of security features.

But even if I grant you that those clients' overall risk profile is
worse than Bitcoin-Qt's, maybe I'm happy to take that risk in exchange
for less setup/maintenance effort. Based on our support requests at
WeUseCoins I know that there are tons of users with < 1 BTC in their
wallets. If my hourly wage is 20$ and I have 20$ in my Bitcoin wallet
then spending one hour per month downloading/updating/figuring-out the
client is equivalent to a total loss.

The list is obviously designed by open-source developers and that's
fine, it's bitcoin.org, arguably we *should* try to push users in a
specific direction, arguably we *should* err on the side of caution in
order to not be caught recommending a hosted wallet that gets hacked.
But if user orientation is supposed to be the focus, then the wiki will
both allow us (because it's less "official") and force us (because users
will have a say) to include even clients we personally wouldn't use. :)


[1] http://xmpp.org/xmpp-software/clients/
[2]
http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features





On 7/9/2012 8:30 PM, Mike Hearn wrote:
> It's easy to say, this page is controversial, so let's get rid of it.
>
> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective. That route spells doom for any product. You can
> always tell when a UI or product is the result of internal politics,
> whether it be the difficulty of plug-n-play hardware on Linux (no
> driver api) to how Microsoft is incapable of producing anything that
> isn't built on Windows. Gmail labs is another example of this.
>
> It makes sense that if I go to bitcoin.org, I am educated about the
> system and what is available for it. It doesn't make any sense to have
> some stuff on the main site and other stuff on a wiki (which may get
> randomly vandalized and looks less professional), based on how
> "controversial" some developers find it.
>
> FWIW I am dead set against anyone randomly changing the website
> without a pull request and such changes should be reverted and
> resubmitted through the proper channels. I don't perceive much value
> in randomization or trying to make this page "fair". If anything, we
> need to pick somebody (one person) who has a strong focus on regular
> people and their needs, then just make them the sole committer to the
> website. That way disputes can be resolved by them making a decision,
> instead of ridiculous edit wars.
>
> ------------------------------------------------------------------------------
> 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
>





  reply	other threads:[~2012-07-09 22:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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 23:07             ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
2012-07-09 18:48         ` [Bitcoin-development] Random order for clients page Gregory Maxwell
2012-07-09 20:44   ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24   ` Amir Taaki
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

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=4FFB5A7E.7020604@justmoon.de \
    --to=moon@justmoon$(echo .)de \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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