On 11/15/2017 05:24 AM, Jason Harrer wrote:
> 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)

Two general points to clarify re: Jason's thoughts:

1. Pledges to one project should only ever make that *same* project lose
pledges due to budget issues. We avoid a wide range of complexities if
we never let projects interact where pledge to one directly drops
pledges to another.

2. The buffer requirement for new pledges removes a wide range of
expensive calculations and volatility. A patron who hit their limit will
need to drop enough to have a good buffer left in their budget or
increase their budget substantially before they can add *any* pledge
back. So, we can avoid all scenarios where someone is almost at their
budget and then comes back active but is again immediately approaching
their budget. Every time a budget is hit, reinstatement will require a
buffer so we don't get pulsing adds and drops of pledges.

Attachment: signature.asc
Description: OpenPGP digital signature

Dev mailing list

Reply via email to