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.

Attachment: signature.asc
Description: OpenPGP digital signature

Dev mailing list

Reply via email to