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)

HTML5 transclusion
Not sure if there is any decent standard being proposed, and I have little hope any single consensus will be adequate.

Therefore, we might as well define a convention local to MediaWiki,


 * Tags will be easy to parse, from javascript, live on server, or as a static archive; plus ESI-time transclusion or possibility of a next expansion phase. In other words, no database required.
 * This requires that there is a fairly simple embedded language(s) to describe the templates / logic.
 * A "trans-namespace" element defines a short name for an arbitrary data source. Enumerate the useful shortcuts (eg. snip a fragment, convert to html, process using a secure js) we want to build-in.
 * The "trans" element is the actual transclusion, and can specify its source using a namespace alias, or the full url.
 * ?Arguments can be given to either the namespace, any transcluded element, or both.
 * Custom hooks can be provided with arbitrary attributes on the "trans" tag.
 * Leave inert tags around the result, which are otherwise a clone of the source tag &mdash; enough information to repeat the operation.

Random CiviCRM notes
CiviCRM Doxygen

TODO:
 * CRM-11566 Navigation often purges session context, with heinous results such as long queries with missing filter criteria.
 * Support event cart: integrate with single event. doubled email
 * Propose that Civi payment processors get sucked out into something generalized.
 * Finish abstraction of templating (also, add pure js methods)
 * Report instance customizations could be saved and retrieved by name, and the built query stored and even 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?