<sarcasm>
Wow, we've made an entire 1.6k out of bitcoin? This totally seems like the
highest-value way to spend our time! Thanks, Bitcoin! I'm sure that the
value of these items won't wildly vary in short spaces of time based on
things like, oh, your propensity to have banking neophytes host your
exchanges and end up shut down.
</sarcasm>
On 10 March 2014 07:39, Andrew Lih <andrew.lih(a)gmail.com> wrote:
Jimmy's already noted this is WRONG, but the
erroneous Telegraph story
reads:
"Wikipedia charity begins accepting Bitcoin donations after co-founder
Jimmy Wales set up a personal account "to play around" with digital
currency and was swamped with cash"
http://www.telegraph.co.uk/technology/wikipedia/10687380/Wales-inundated-wi…
*Jimmy Wales* @jimmy_wales <https://twitter.com/jimmy_wales>
7m<https://twitter.com/jimmy_wales/status/443031310207311872>
Yo, @Telegraph <https://twitter.com/Telegraph>, this story is wrong:
http://www.telegraph.co.uk/technology/wik
ipedia/10687380/Wales-inundated-with-Wikipedia-donations-after-publishing-personal-Bitcoin-address.html
... <http://t.co/fM3CTBzRsE> No decision has been made for Wikipedia to
accept BTC!
On Mon, Mar 10, 2014 at 9:26 AM, Charles Gregory <wmau.lists(a)chuq.net
wrote:
Hi everyone,
I thought it may be worth pointing out that this conversation has be
re-opened by Jimmy on
reddit:
http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_w…
<
http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_w…
On it he states "I'm planning to re-open the conversation with the
Wikimedia Foundation Board of Directors at our next meeting (and before,
by
email) about whether Wikimedia should accept
bitcoin." More info at the
thread itself.
Regards,
Charles / User:Chuq
On Fri, Jan 10, 2014 at 10:44 AM, Katie Horn <khorn(a)wikimedia.org>
wrote:
> That very rough number that Matt threw out there has far less to do
with
the cost
of applying human brainpower than it does with the cost of
taking
the available brainpower away from things we know
are going to
significantly increase our efficacy. We have several of those things
looming on the horizon, and we choose to concentrate new development on
what we know will be the biggest earners out of those.
My understanding (I am no analyst) is that we continue to have a
difficult
> time finding hard evidence that bitcoin is currently anywhere near the
> other top candidates, so it remains off the roadmap in favor of
> concentrating on solid numbers. If anybody would like to supply us with
> hard figures, we'd certainly be interested in seeing them.
>
> The main reason the expected earnings > one dude's salary calculation
of
worthiness doesn't work here, is that there are four people in
fundraising
> engineering. The four of us support and maintain all existing payments
> functionality, ensure integrity of the donation pipeline, and do all
new
> code development and review. For the sake of
the foundation and the
> movement, each one of us has to do significantly better than
individually
break
even.
As the fundraising tech lead, I definitely appreciate any outside
interest
> in potentially helping us out by modifying fundraising code in order to
> support more payment methods, and I would be happy to outline the
general
process
of integrating with a new gateway in a way that is consistent
with
our current code.
Before I get in to the nitty-gritty, though, I want to be completely
clear
> on this one point: Even if I had the authority to do so (I do not),
there
is no
universe in which I am willing to enable new functionality simply
because the switch exists. Matt has already done a pretty good job
outlining the scope of the collective distraction that bitcoin
represents,
> and that scope extends well beyond tech. In fact, it seems to me that
> producing the actual integration code is the most trivial issue
regarding
> bitcoin integration that has been brought up
thus far, and I would not
be
pleased
to see well-intentioned volunteer time go to waste over hastily
dismissed blocking issues which exist well outside the purview of the
fundraising tech team.
That said, here is a very general 30,000 foot view of a typical new
gateway
integration from a purely technical standpoint:
* Donation Interface[1]: This is the mediawiki extension that initiates
payments. A new gateway adapter child class will need to be created,
which
will run in parallel to the existing enabled
gateway adapters, and not
short-circuit any of the class constraints that have been deliberately
built in to the gateway adapter parent class. Then, an appropriate form
(or
> redirect) should be created to handle the user experience, which uses
the
RapidHTML
templating system. At the end of it all, after a successful
donation has been made, an internal donation message should be queued.
Happily, examples of all the things I just mentioned already exist in
other
gateway adapter objects; New gateways are rarely
so unusual that we
haven't
nearly done it before.
* Payments Listener[2]: Most payment gateways worth even brief
consideration, have an optional near-realtime notification system. This
system tells us when we receive new payments, and existing payments
change
status (cancels, refunds, chargebacks). We would
need to create a
listener
> to receive realtime payment updates, process them securely, and queue
> donation messages when appropriate. Though a realtime message listener
is
> usually not strictly required in order to
get paid through a new
gateway
integration, I have recently decided to require them wherever possible.
* Nightly reconciliation / auditing[3]: Every payment gateway we
integrate
> with provides a daily downloadable list of all the transactions we
should
have on
record. So, a job needs to be created that will download the
daily
file and chew through our records to make sure we
have all the relevant
data, and rebuild anything we may have missed. This job needs to be set
up
to run daily.
* Queue consumer module for civicrm integration[4]: The donations queue
consumer will need to be modified, to accept and correctly process
donation
> messages from the new gateway, in a way that is consistent with our
> existing data.
>
> Of course, all of this work will require pretty consistent code review,
> which will bottleneck on the same four fundraising engineers. As it
> happens, the number of non-fundraising engineers who are willing to
code
review
for fundraising without special encouragement, has historically
been
so close to zero it's almost not worth
mentioning.
In the event that any volunteers are willing to take this on, I have
three
> things to say:
> #1 - There are no guarantees that your code will ever be enabled by the
> WMF. Ever.
> Yes, I already said it. It seems important enough to mention twice.
Even
if
the tech team decides your code is beautiful and
flawless and we love
you,
it is still likely to end up an overblown
expression of futility that
spans
> four codebases.
> If this isn't a problem for you, by all means: Go for it.
> #2 - To greatly increase the likelihood that your code will be
reviewed,
looked on
favorably, and eventually merged (not enabled, though. Not my
call. See #1), you should probably get in contact with the fundraising
tech
team and keep us informed about what you're
up to. The best way to do
that
is to get in contact with us on IRC. There are
usually a few of us tech
types in #wikimedia-fundraising, so that's probably the best place to
start
looking for specific guidance.
#3 - Just kidding; It's #1 again.
-Katie Horn
Fundraising Tech Lead
Wikimedia Foundation
[1] - Donation Interface:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Donati…
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/Smash…
[3] -
Reconciliation and Auditing: At the moment, our auditing code is
not
> centralized. Some of it is in the CRM repo (below), and some of it
lives
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools…
[4] -
Donations Queue Consumer:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,b…
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg <jayvdb(a)gmail.com>
wrote:
> On Jan 9, 2014 11:38 AM, "Matthew Walker" <mwalker(a)wikimedia.org>
wrote:
> > >
> > > I will probably regret saying this[1] -- but the figure we like to
> throw
> > > around here in fundraising tech is that a new payments gateway [2]
is
> not
> > > even worth considering unless it is likely to make us at least 500K
> USD a
> > > year[3].
> >
> > Thanks for putting a number on the table.
> >
> > It is a tad higher than I expected, being more than several very
highly
> > paid person years, but it is a starting
point.
> >
> > In case an enthuiast who can code is reading this thread, which
> repository
> > needs bitcoin support?
> >
> > --
> > John
> > _______________________________________________
> > Wikimedia-l mailing list
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>