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-with-Wikipedia-donations-after-publishing-personal-Bitcoin-address.html *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 <[email protected]>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_wikipedia/ > < > http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wikipedia/ > > > > 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 <[email protected]> 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/DonationInterface,branches > > [2] - Listener: > > > > > https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashPig,branches > > [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 > in > > > > > https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools,branches > > [4] - Donations Queue Consumer: > > > > > https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,branches > > > > > > > > On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg <[email protected]> > wrote: > > > > > On Jan 9, 2014 11:38 AM, "Matthew Walker" <[email protected]> > 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 > > > [email protected] > > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > > <mailto:[email protected]?subject=unsubscribe> > > > > > _______________________________________________ > > Wikimedia-l mailing list > > [email protected] > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:[email protected]?subject=unsubscribe> > > > _______________________________________________ > Wikimedia-l mailing list > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:[email protected]?subject=unsubscribe> > _______________________________________________ Wikimedia-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[email protected]?subject=unsubscribe>
