Page MenuHomePhabricator

Spike: investigate smashpig next steps
Closed, ResolvedPublic


What are the parts of smashpig that we absolutely have to do to keep ourselves sane?

Please list this in either phases or sections of useful work.

If possible add our usual sizing beside each section:


  • Phase 1 (medium)
  • Phase 2 (medium)
  • Phase 3 (Big)

Must haves:

  • item 1 (medium)
  • item 2 (medium)
  • item 3 (Supersized)

nice to haves

  • item 1 (big)
  • item 2 (big)
  • item 3 (medium)

Event Timeline

DStrine created this task.Jan 31 2017, 10:36 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 31 2017, 10:36 PM
DStrine updated the task description. (Show Details)Feb 8 2017, 5:43 PM

The way I figure it, we should break this work up into phases necessary to complete before we can comfortably start trying to find people who might use these libraries, without *them* going crazy / getting fed up / never speaking to us again. Off the top of my head, that looks something like this:

Phase 1: Smashpig code becomes independent of Mediawiki code (with the understanding that nothing we rely on is broken in the process: DonationInterface uses the now-independent Smashpig libraries, translations still work, config settings do what they are meant to, etc.)
Phase 2: There is a clean and easyish way to write a thin shim to integrate Smashpig libraries into other systems as extensions / modules / whatever terms those other systems use. We demonstrate this by writing one for both DonationInterface and civicrm, and using both in production. (we will know this is done when code related to recurring transactions can be cleanly deployed, and someone could run smashpig payment forms straight from civicrm, and payments wiki still works like nothing particularly interesting is going on)
Phase 3: One solid pass of refactoring, to make it as easy as possible for outside parties to add their own payments integrations, create payment forms and workflows that use smashpig, create shims to other systems we don't use, or whatever else they want to be able to do. This should involve one or more 3rd parties to work with to gather their real hopes and frustrations, so we can concentrate on solving problems that actually exist.
Phase 4: Get other people to use it and see what happens. This is firmly outside the scope of this task.

@Ejegg : Does this make sense to you as a rough outline of phases for the team to investigate?

Ejegg added a comment.Feb 15 2017, 9:56 PM

@K4-713 SmashPig is already independent of Mediawiki and CiviCRM code. We're happily free of any circular dependencies there, so maybe we can consider Phase 1 all done. Or do you think Phase 1 includes pushing all the DonationInterface settings and the translation into SmashPig?

For Phase 2, we need to decide whether SmashPig will actually extend to the forms. I've been considering the forms to be on the DonationInterface side of the fence. SmashPig would certainly be more useful if you could drop it in and get forms, but we don't want to lock users to one particular library for session handling, request handling and i18n, do we? Think we could define interfaces for all those services?

How about this?
Phase 1) Push all i18n up to the forms layer (T130669) and push smaller (not the adapters, but maybe DonationData) non-UI classes down from DonationInterface into SmashPig. (medium)
Phase 2) Recreate the adapters in SmashPig, starting with the Ingenico re-integration. Will need to do session and request related stuff against a standard interface. (Big)

Same phase 3 and 4 as above

@Ejegg Yes, I was envisioning Phase 1 being not SmashPig as it is now, but SmashPig as all the meaty payments integration stuff that currently lives in DI. Sounds like your Phase 1 and 2 are more specific bits of my phase 1, so I have to add 1 to the rest of my phase numbers to square it all up.

As far as forms go: Whatever we decide, should be optimized around getting new people to a place where things work quickly. I suspect that means supplying some default forms as part of the framework shims, and a way to easily drop in new custom forms that are A/B testable against eachother. This is probably harder than it sounds...

awight added a subscriber: awight.Mar 1 2017, 8:00 PM

I'm not sure if I should rename this spike title to reflect the much broader scope of our discussion, cos the original task is a useful one, to identify the *next* steps. I agree with the direction the conversation is going in, though: we don't know the next steps yet because there's no roadmap.

And before we create our roadmap, we might want to identify the requirements. Which is tricky cos we're currently the only stakeholders...

DStrine closed this task as Resolved.Mar 1 2017, 11:53 PM
DStrine moved this task from Review to Done on the Fundraising Sprint Deferential Equations board.
mmodell removed a subscriber: awight.Jun 22 2017, 9:44 PM