On 11/07/2017 04:34 AM, Bryan Richter 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. >
We discussed this a while back. I'm going to summarize again here some basic (maybe obvious) factors. We only need to check for budget-limits at the time of new pledges, and any budget limits hit will only affect the patrons of the project that received the new pledge. While this may eventually be computationally intense, it won't be too extreme early on. The process as I'd expect would be to check the budget status of all the existing patrons to one project when that project receives a new pledge. It could be done in some sensible order such as oldest patron first. As soon as a single patron is determined to go over their budget, their pledge is deactivated and no further budget checking is needed. If the checking gets through all the patrons without issue, then nobody is over budget. > 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 Why deprecate pledge_since? Certainly we don't want to lose the information about how long someone has been a patron. Also, my idea (not sure it's strictly the best though) to check in order from oldest to newest pledge would seem to use some information like this. > - 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. > Are you suggesting that staying pledged but over-budget between crowdmatches will happen? That trade-off may be necessary, but we should clarify. From the front-end perspective, the assumption is that a patron is notified of hitting their budget *before* the crowdmatch happens so that they can choose to adjust their budget or their set of pledges prior to the crowdmatch (unless the budget was hit with too little time before the crowdmatch). Overall, this does bring up a ton of questions. There needs to be some understanding between front-end design and dev here. Front-end has to work with that is practical for dev, of course. ### concerns If multiple patrons hit their budgets at the same time (say they pledge to the same set of projects), who gets dropped first? If a patron with a dropped pledge decides to drop a different pledge in order to reinstate the dropped one, I guess any patrons who also support the same two projects would be budget-wise unaffected since they would just reduce their level for one and increase for the other. I guess it would be unlikely for their to be multiple patrons all close to their budgets at the same time if the set of projects they support are really different sets, right? BUFFER: to keep things from being too volatile, we've had this concept for a long time that there should be some buffer remaining in a patron's budget in order to add a new pledge. Keep that in mind (and consider implementation plans). I'll stop here except to reiterate: what about doing budget calculations at the time of pledging? I thought that would be effectively the only thing needed. Then the crowdmatch and payment events would be at most just extra checks to be triple-sure to respect budgets…
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
