On 11/16/2017 12:29 AM, Aaron Wolf wrote: > On 11/07/2017 04:34 AM, Bryan Richter wrote: >> >> 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. > > <snip>
As you said in the other email on this thread, I think the most important adjustment to my plan is making sure that a pledge to project A only affects other pledges to project A. I agree with that requirement. I'll think through the implementation ramifications and come up with a modified plan. >> - 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. I was unclear there. Definitely keeping that info. It's just going to be part of the Pledge table instead of the Patron table. > ### concerns > > If multiple patrons hit their budgets at the same time (say they pledge > to the same set of projects), who gets dropped first? It can't happen at the *same* time - each pledge is atomic. It might be too fast for human comprehension, but the system will have a notion of ordering, so it'll use that to drop them. > 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. It would only totally unaffect patrons who are also pledged to both projects. If someone gets dropped from A and chooses to pledge to B instead, patrons pledged to B (but not A) could get dropped. But there is no reason to consider this a special scenario. It's two unrelated pledge+drops, only tenuously connected because the drop-ee in one scenario is the pledger in another. > 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). Buffers can't exist in a system that has no account balances. The volatility gets pushed to the question of "Does the patron have enough money in their actual bank account." > 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… Yeah, doing them at pledge time is probably going to be required.
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev