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.



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 
        -  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 

Attachment: signature.asc
Description: OpenPGP digital signature

Dev mailing list

Reply via email to