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

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…

Attachment: signature.asc
Description: OpenPGP digital signature

Dev mailing list

Reply via email to