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

Reply via email to