Thank you for stressin' the system with large numbers of small contributions — the average donation is $20 USD. This more than anything else allows us to remain independent. See "The Revolution Will Not Be Funded", edited by INCITE! Women of Color Against Violence for a discussion of some of the reasons why relying on large donations might be harmful to your health.
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.
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.
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.
- Submissions/Collaborative_drafts, a discussion I'd like to have with editors about making "Undo" more friendly.
- See a human-readable description in IdeaLab.
- 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.
- Please read Peter Gallert's explanations of why the Wikipedia project would benefit by inviting Indigenous knowledge.
- 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)
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,
- 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 — enough information to repeat the operation.
|Babel user information|
Random CiviCRM notes
- 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"
- 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?