User:Adamw

Software developer employed by Wikimedia Foundation, working in the Fundraising tech group. Thank you for stressing the system with large numbers of small contributions — the average donation is $20 USD

= Membrane payments library = I'm using this code-name to describe a concept we may or may not want to use when generalizing the payments library currently embodied in DonationInterface and queue2civicrm.

Tiered data
There is currently a hierarchy of data for each donation, which is "staged" as it flows towards the payment gateway, and "normalized" for internal operations. I think this can be generalized to an arbitrary set of data systems, and events that cause each transformation.

Componentization
Almost all of the data can be handled in disjoint units such as "donor", "address", and "gateway transaction". I propose splitting the data and processing into these groupings, in other words, find a way to represent them as separate classes. For lack of a better name, I'm calling these "facets". I think that gateway-specific logic, tracking, and spamfraud validation can all be conveniently represented as classes of the same type, which provide event hooks to accomplish their functions.

Prototype
Some choppy initial work is gathered in a sandbox branch called "membrane"

= Related projects =
 * Part-time developer for OneCommons, a wiki written in python.
 * Use any bibliography as a lending library collection (see also Halfway Free Library and Bemuse)

= Moonlight interests, Mediawiki: =

Offline Editorship

 * Extension:Nonlinear for branching article revisioning
 * Would decouple resolving any nontrivial three-way merge from making the edit itself.
 * Represent revisions as a delta. Allows better asynchronous editing.
 * The new visual editor will likely batch operational transformations, there's yer delta.
 * Deltas would have N=||cross product|| possible combined resolutions, depending on a choice of selection. Article state at any time could be ambiguous, and multiple.
 * Extension:Protection: article protection is too difficult to improve, because it is currently managed by MW core code. Once these permissions have been componentized, it will be more clear how to hook in alternative permission schemes.
 * Extension:Offline will
 * Currently, this extension can more or less efficiently read the .xml.bz2 format.
 * The next big move would be to read archives in OpenZIM format, but this is modified HTML and not wiki text. Perhaps OpenZIM can be re-specified to include markup source.
 * Unfortunately, this extension requires a minimal LAMP stack, which makes it a poor fit for mobile devices.
 * Extension:Parsoid will produce an embeddable library that can parse, render and edit wiki markup. This will eliminate the LAMP requirement for offline interaction.

Random Fundraising notes

 * payments library turned into a component


 * queue_handling:
 * failed queue pull takes c. 30 sec to timeout
 * amount / 100?
 * Integrate new failed queue with qc


 * recurring_globalcollect:
 * reset contribution_recur failure count after a success?
 * end_date query is broken
 * Review exceptions; error prefix was probably lost; are we still relying on drush_top_error?
 * Is making contributions even on failure?


 * DI needs to complain if limbo queue isn't configured


 * payment_library: functionize value overrides


 * Report customizations could be saved and retrieved by name, and the query optimized by hand


 * Check that receive_date is always set in UTC, let Civi know

Chapter CiviCRM

 * Chapters use several Civi extensions coded by Holger Motzkau and Manuel Schneider for wmse.
 * Configuring Civi with these extensions is not trivial, automation is in progress
 * There is a backlog of chapters needing Civi orientation.


 * What are WMF's requirements for CiviCRM, and which map to upstream core improvements or modules?