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_wi...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 khorn@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/Donatio... [2] - Listener:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashP... [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,... [4] - Donations Queue Consumer:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,br...
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg jayvdb@gmail.com wrote:
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe