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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
