Figure out the current crowdmatching situation assuming zero carry over from previous months.
If a pledge needs to be auto-dropped on that basis, auto-drop it.
If there are any carry-overs from previous months, use [limit minus sum of current pledges] to pay them off in whole or in part, paying off oldest ones first.
My concern:
Carry-over was introduced to solve the Box-not-filled-enough-problem™. This seems to make use of it in a Box-is-filled-to-the-brim-problem™.
But actually that’s what the Limit should solve by by kicking out stuff that does not fit.
We would suddenly be using carry-over to fill up the box as much as possible and try getting as close as possible to the limit! Are we using our tools right here?
I think you have it right. All this ado is about understanding the ramifications of adding carry-over functionality. This is why implementation takes a long time – you have to think through every corner case, no matter how minor, that the program might end up in!
EDIT: What I mean is, although we are adding carry-over to solve the Box-not-filled-enough-problem™, because carry-over exists we might conceivably find ourselves in the Box-is-filled-to-the-brim-problem™. By solving the former, we force ourselves to have a solution to the latter, as well.
I like this framing. Here’s another: Your budget limit is actually providing two separate guarantees:
The Sum guarantee: In any given month, your pledges + fees will never exceed your budget.
The Charge guarantee: In any given month, your credit card will never be charged more than your budget.
@msiep, what if we consider dropping the Charge guarantee? It makes the budget limit very powerful, by giving the user absolute control. That’s great, but do we need it for alpha, given the extra complexity it adds? We could always add it back in at a later date if we get feedback that people aren’t comfortable pledging or were surprised that they received a charge greater than their limit.
For example, I don’t personally care about the Charge guarantee. If my pledges roll over for a few months and it causes the first charge to exceed my budget, I don’t feel like my limit has been violated, since I know I wasn’t charged last month for a donation I made at the time.
What I mean is: we have a solution for that already, but we create an extra solution with extra rules. Pledges can fill the box to the rim and the limit takes care: Out the window! – vs. – Carry-over fills to the brim and it gets to “weasle” its way around the limit and split up. Why add the extra function?
We may run into problems when calculating the actual experience of having one small project and lots of carry-over over a long period of time. But that is probably because we’re sandwiched between minimum 4$ and maximum 5$. Maybe we need to set the initial max to 10$ to make the natural expected carry-over dissolve gracefully without extra rules?
I would not be against it: it simplifies the handling and solves the problem elegantly.
I’m concerned about the clarity of how pledges, fees, budget, charge and limit interact.
In that case the carry-over would not be part of the budget anymore, but part of the charge and could exeed the limit. Where would the dashboard show this AND convey that the limit you can set does not apply to this?
Maybe there could be an extra entry/box under the the NOW-box… I’d have to think about that apporach some more…
An alternative would be, setting a budget limit of $5 lowers the minimum charge, so iit’s impossible to be sandwiched, although this would incur higher fees.
A more complicated alternative would be to allow the user to select whether they care about the Charge guarantee, and only allow them to check that option if the budget is above a certain minimum.
In my view, the problem is all in fees. If we didn’t have to worry about fees being part of the budget, it would be really easy to show this. Here’s a quick little wireframe/mockup I made (apologies for bad handwriting and low quality photo):
note: I initially forgot that I wasn’t including fees, so they’re actually in the November and December cards. Just ignore that…
The way Patreon handles this is by hiding the fees from users, and just taking them out of the projects’ income. I don’t like that approach, but I will admit it is challenging to visually communicate how fees interact with the budget limit.
I think mray has strong enough concerns that we should discuss this in the future. However, I also think it is enough of an edge case that we can successfully postpone the discussion for months or years.
Let’s please put a pause on this discussion, and choose more pressing items to work on. Thanks.
Already the status quo. The current live site sets $10 initial budget.
So, indeed should nearly-always be room to include all outstanding carry-over within first charge, no need to split up the outstanding balance.
Only picky issue: we still need some rule for what happens in the rare edge-case, but that isn’t worth debating much since very rare. Either the proposed split over a few charges or allow rare one-time charges beyond limit. The program has to do something. I see pros and cons either way and don’t care to be involved in the decision.
I think this is a misunderstanding. We are not in any way using carry-over to “fill up the box as much as possible”. However, we have to in some way deal with scenarios in which we can’t pay off the full outstanding carried over amount without exceeding the limit.
I think it’s very important to have a clear and easy to communicate type of limit “you will never be charged more than $limit”. The fact that these scenarios won’t happen very often doesn’t change the fact that we have to communicate “How It Works” to every single person who visits the site. We need that to be simple and trust-inspiring.
If there are any carry-overs from previous months, use [limit minus sum of current pledges] to pay them off in whole or in part, paying off oldest ones first."
…and I don’t think anyone has been saying this is too hard to code.
That would not get rid of the edge case. For example:
Patron pledges to project A with about 500 patrons.
Pledge value of around $0.50 builds gradually over several months toward minimum charge.
When total-including-carryover is about $3.50, not quite enough to trigger a charge, but close, patron pledges to project B with 8,000 patrons (maybe we just got a big prominent project on board).
Limit of $10 is sufficient for project A and B without carryover (around $8.50) so no auto-drop happens.
Limit of $10 is not sufficient for project A and B plus carryover (around $11.50).
Note that in this type of scenario, with Snowdrift as project A and some very well known project of the type we’re hoping to get as project B, this could actually happen to a LOT of people at once - exactly when we especially want this big influx of people to have an excellent experience.
It is a month that is over limit. The Limit cuts through the carry-over like a hot knife through butter if I’m not mistaken; creating a new “overhang-carry-over” that has to be dealt with next month, because that very month is now filled to the brim with carry-over.
My problem here is: I don’t see why the limit does not kick in to drop “Another Project” : done.
The months is over limit after all!
We tell people:
“Carryover is for too empty months and avoiding too high fees.”
“The Limit makes sure you never pay more.”
Then we use Carryover for circumventing the limit. Not good. Also not easy to find a solution to convey it visually for me.
I, too, would be upset if one of my pledges were dropped this month… because they were too low last month? That seems like a bizzare and nonsensical chain of events.
I think it makes sense to put everything in the budget. One inconsistent side effect for example is: you have two January cards there, one of them not being a “month”.
I agree, I was just showing how that is the cause of complexity.
One’s a credit card charge event, one’s a crowdmatching event. You could visually distinguish them even more, rearrange the cards into two columns, or even show the charge events on a different page.
Please don’t get caught up in the details of an unpolished example that was being presented as an illustration of a concept, not a proposal of a final design.
We are not using carryover to circumvent the limit. The October 2017 wireframe example you showed is not a month that is over limit. It’ a month that is below limit and we’re using what is left of the limit to partially pay off carryover. Here’s how it’s below limit:
0.98 + 3.42 = 4.40
Stripe fee on 4.40 would be 0.44
Total including Stripe fee would be 4.84, below the limit
We have 2.25 of carryover to pay off, but can’t pay all of it off without exceeding the limit, so we pay as much of it off as we can by charging exactly the limit. This actually gives me an idea of how to better show this in the wireframe. I’ll try it and see if it helps.
As for conveying it visually, let me try my wireframe idea and maybe that will help with that too. If not, we can discuss that challenge in itself.
This seems to be a decision that @msiep set and makes sense and discussion should end:
That outstanding carry-overs do not have to be charged all at once (after all, the represent multiple months, so the total over all this process will both always be below each month’s charge limit and be below the total budgeted over the time period, it’s not violating any budget limit in any way).
And a secondary issue that should be focused on and figured out:
That presenting the idea that there is any obligation that can be only partly charged risks a loss of trust because patrons could fail to understand what is going on and feel that something funny is happening. If they see obligations wrapping up and budgets topping off to the brim, they could (wrongly) worry that the budget is merely capping charges while obligations are allowed to grow indefinitely and put them in debt…
So, I think it is important to work out the presentation so there’s as little room for misunderstanding as possible. I have no suggestions on how to do that. Of course, worst case is we go with something we hope will work and it turns out to cause confusion, so we need to change later. We need to be ready to do that instead of getting things perfect now.
I am also interested in continuing the discussion with @mray to, in his words, “be on one page when it comes to the basics.”
However, I don’t think that’s worth spending anybody else’s time on other than @mray and myself, so I’m going to take it to a private conversation. Ping me if you want in and I’ll add you, but please consider not — we’ll share the end result of the conversation if anything constructive comes from it.
