After thinking about it for awhile, I'd like to propose an alternate recommendation for the crowdmatch step under budget calculations. I will start off saying that your approach will be far simpler to implement and less resource-intensive than mine, however I'm still proposing my recommendation based on prior conversations that were made pertaining to letting the patron decide what projects are their priorities (note: I'm not suggesting that we set that up now, rather I believe my recommendation would better accommodate that functionality should you decide to implement the patron prioritization *later,* so it may be beneficial to look at and possibly set up the alternate approach now to prepare for future changes).
The idea is to set up one or two temporary "tables" (not sure if it would be preferred to do this via postgresql or simply have two mapped lists via Haskell, so I will use the term "tables" to represent whatever this agreed-upon structure ultimately is). The first "table" would hold the calculated pledged dollar amounts per project (at this point, the calculation assumes no one has exceeded their limit). Then, the automation will review each patron to determine if any exceed their limit. If so, the system needs to drop a/multiple pledge[s] to get the user under their limit. I recommend the logic to drop the multiple pledges be a separate function that is called from the primary logic (thus allowing you in the future, should you decide to go down that path, to easily switch out the logic from a LIFO/FIFO function to a patron prioritization function or any other type of function that you think of later) and adjust the temporary "table" pledged dollar amounts accordingly. Optionally, as an addition to the last paragraph, the logic could store the dropped pledges in a second temporary "table". The idea behind the second "table" is this: Once all of the adjustments to the project calculated pledged amounts are made across all the patrons, this may reduce down the pledged amounts of enough projects that a patron pledged to that we might actually be able to add some pledges back in, should we want to go down that road. The con is obviously complexity: This would mean a second pass to review the dropped pledges and determining if adding a pledge back in would impact other patrons, so there'd be a LOT of additional calculation needed to ensure that adding back pledges doesn't cause other issues. The pro, though, is that we could be getting additional funds to the projects. Obviously, the call is yours, but I wanted to put the idea out there for you to ponder upon. - Jason (JazzyEagle) On Tue, Nov 7, 2017 at 6:34 AM, Bryan Richter <br...@snowdrift.coop> wrote: > Hi all, > > Here are some initial ideas for implementing multiple projects in the > crowdmatch library. (This is not about the website.) Please take some > time to read this and provide any feedback or fresh ideas, since I > dreamed this up on my own, and I could use some second opinions. > > Thanks! > > --- > > > Having multiple projects means it becomes more complicated to see if > someone has gone over their budget. We'll need to account for that. > > Crowdmatching and payment processing both become more complicated, > too. Besides checking budget limits (which will have a life of their > own for the sake of early warnings), crowdmatching will have to group > by project when calculating crowd size. > > The existence of a pledge will need to change from being a Maybe field > in the User row to being a Maybe field in the Pledge list. It stays > a Maybe so that one table handles the whole relationship: pledge > status and pending donation. > > Here's the plan for handling spending limits: Don't charge more > than the limit, and don't allow a crowdmatch that is greater than > the limit. Note what's left out: we do not consider the pending > balance (if any) when doing a crowdmatch, but only the spending limit > itself. In the possible case that a crowdmatch of, say, $3 causes a > user's balance to be $11, they can pay $10 this month, and $4 next, > and that's fine. > > We need is to extend the calculations to be per-project, hitting the > pledge table instead of the user table. > > - Tasks for enabling multiple projects > - Dev tasks > - Modify tests to assume multiple projects > - Create new Project table (id, handle, donations_received) > - Create new Pledge table, user <*--*> project > - Deprecate pledge_since > - Implement budget limit calculations (below) > - Deploy tasks > - Migrate pledges and pending donations > - insert into pledge (project, user, since, pending_donation) > select 1, u.id, u.pledge_since > from user u > - Budget calculations > - During crowdmatch > - Drop pledge LIFO, recalculate, and repeat until nobody exceeds > their limit > - Continue with crowdmatch > - When patron views a page > - Change nothing, just show warnings > - During payment processing > - Only charge up to the limit, leaving any extra in the patron's > account. > > > _______________________________________________ > Dev mailing list > Dev@lists.snowdrift.coop > https://lists.snowdrift.coop/mailman/listinfo/dev > >
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev