Page MenuHomePhabricator

Hackathon idea: Make the DonationInterface extension as friendly as possible
Open, HighPublic0 Estimated Story Points


We need to make it easy for developers outside of the fundraising tech team to contribute to this extension.

In a nutshell, I want to come out of the other end of the hackathon, with an entirely new layer of dummy 3rd party accounts (one for every payment gateway) that will allow developers to be able to work on and test DonationInterface code locally on their own machines, with minimal setup and no actual need to communicate with 3rd parties. I'd also like to think of clever ways to make appropriate levels of developer-friendly information appear when you are using those dummy accounts, and just generally make it more pleasant to be working on that stuff in the first place.

For contrast: Right now, you can't even install the extension and get it to do anything but emit a bunch of errors unless you have some appropriate credentials. Most people have to give up right there. In fact, nobody at all has gotten any farther than that in years unless I hired them specifically to work on that code, and I usually have to (securely, which is a whole other mess) send them an abridged version of my LocalSettings before they can even get an initial form to load.

We want to work with people who have never tried to install DonationInterface before, so we can see where the process is falling down for normal people after we implement each of the steps outlined (shortly) in subtasks.

Installing the Fundraising tech development environment

Take a look at the INSTALLING docs, you will want to install MediaWiki-Vagrant and enable the "fundraising" role.

Once you have provisioned a box, you should be able to read the built-in documentation which will lead you further.

Iterative list of Goals approximate chronological order. However far down this list we get, would be grand.

  1. Installing DonationInterface with no extra settings or 3rd party credentials, should not blow up your entire MediaWiki instance.
  2. T99954: In the event that credentials for a gateway are not supplied, that gateway should go in to local development mode.
    1. It should be inescapably obvious to the user, whenever they are in local dev mode… but not in such an extreme way that we couldn’t use this technique to finally allow selenium tests to be possible.
    2. In local dev mode, there will be no attempts to actually contact third parties. Ideally, this would be rendered impossible within all gateways in local dev mode.
    3. Short-circuit all FormChooser safety checks, for any gateway in local dev mode.
    4. All 3rd party responses and workflows will be faked when we are in local dev mode.
    5. When a gateway takes you to a piece of the workflow hosted by a 3rd party, local dev mode will allow the user to supply the values for expected parameters that they would like to be pretending to receive from the 3rd party.
    6. For all gateways, if the user is typically sent away to a third party and expected to return, it should always be possible in local dev mode to get 100% of the way to the Thank You or Error page by very thoroughly faking the external bits, internally.
  3. T99955 - Write browser tests (Selenium and/or Cucumber) that work in local dev mode.
  4. T99957 - Write MW-Vagrant puppet to allow us to spin up dev, staging, and testing instances, and deploy sandbox servers on WMF-labs.
  5. We should swap the queue out for Redis during normal development, cos it's already provisioned and will save precious VPS resources. Currently we are coupled to ActiveMQ, but see completed preparatory work in the code, which wraps queue access in an abstract shim, T92916.

Related Objects

Event Timeline

atgo assigned this task to K4-713.
atgo raised the priority of this task from to Needs Triage.
atgo updated the task description. (Show Details)
atgo added a subscriber: atgo.
K4-713 set Security to None.
K4-713 updated the task description. (Show Details)
K4-713 renamed this task from Hackathon idea: Make DI Friendly to Hackathon idea: Make the DonationInterface extension as friendly as possible.Feb 14 2015, 2:32 AM
K4-713 updated the task description. (Show Details)

Should the words "Vagrant" or "Labs" be part of the description of this project? I'm asking out of ignorance, but these seem to be two axis where our developer outreach efforts are aligning to.

awight triaged this task as High priority.Feb 24 2015, 7:26 PM
awight updated the task description. (Show Details)
awight added subscribers: Ejegg, pizzzacat.

Should the words "Vagrant" or "Labs" be part of the description of this project? I'm asking out of ignorance, but these seem to be two axis where our developer outreach efforts are aligning to.

T78739: Vagrant Fundraising role needs to be able to run a specific MediaWiki branch is about MediaWiki-Vagrant. Mostly it is about finding a way to run a separate MediaWiki branch for the Fundraising wiki.

Should T78739: Vagrant Fundraising role needs to be able to run a specific MediaWiki branch block this task or are they unrelated? Would it make sense to include that task in the plans for Lyon? I'm just trying to add critical mass around interesting areas of the hackathon (see T89084#1065426).

By the way, it would be useful to know about travel plans of the Fundraising Tech team beyond @K4-713 .

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

awight edited a custom field.
awight edited a custom field.
awight added a project: Epic.
awight updated the task description. (Show Details)

We are trying to help all open tasks listed under "Work continues after Lyon" at the Wikimedia Hackathon 2015 workboard finding their best way forward. * If you are participating in Wikimania, consider adding the #Wikimania-Hackathon-2015 project to get this task in that loop, which is about to start. * If you think this project could welcome help from a dedicated Google Summer of Code or Outreachy intern, or from an Individual Engagement Grant, add the Possible-Tech-Projects project. * If you would like to receive some other type of support (organizing a Tech Talk, establishing contacts with existing developer teams in Wikimedia or elsewhere, travel sponsorship for a related activity... you name it), please create a subtask explaining your request and associate it with Developer-Advocacy (or you can start by commenting here if you prefer). * Keeping the description, priority and assigned fields up to date always helps. :) For some context about this message, see T101151: Evaluate which projects showcased at the Wikimedia Hackathon should be supported further. It is the last communication related to Wikimedia-Hackathon-2015 that we will post here.

Aklapper added a subscriber: K4-713.

@K4-713: Resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!).
Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task.
Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - thanks!