User:Adamw



Adam Roses Wight. Software developer employed by Wikimedia Foundation, in the Fundraising tech group.

Thank you for stressin' the system with large numbers of small contributions — the average donation is $20 USD.

= Fundraising projects =

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. Facets can be composed as an ordered set.

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

= 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 is a stopgap offline editing mode for wikipedia.
 * 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.

= 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)

Random CiviCRM notes
CiviCRM Doxygen

TODO:
 * CRM-11566 Navigation often purges session context, with heinous results such as long queries with missing filter criteria.
 * Report instance customizations could be saved and retrieved by name, and the query optimized by hand
 * Civi needs a timezone overhaul
 * Install process doesn't need to be so non-standard. It could be a multi-stage form under "update.php"

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?