Feedback wanted re pledge suspension, auto-drop, etc

Clearing the Path
18

Having read the above, I think we should keep it as simple as possible for MVP and for now defer further discussion of possible post-MVP changes. Here’s my revised proposal. Despite aiming to keep it simple, I did add something I didn’t include before, which is that if auto-drop happens, that fact is visible on the web site, not just in an email notification. I think that’s important.

MVP:

  • Random “auto-drop” (no concept of “suspended”) occurring immediately if your “if crowdmatching were done now” scenario would exceed your limit as a result of an increase in patron count to one of your projects.
  • Carry over from previous months will never trigger auto-drop; if necessary it will be carried over again until it is paid off.
  • If the auto-drop conditions apply to multiple patrons at the same time, one is selected at random for auto-drop. The calculation is then repeated since the patron count changed, and any additional auto-drops are triggered until no further auto-drops are needed.
  • Patrons receive a warning notification if < $threshold away from their limit (via email and on website).
  • Patrons receive an auto-drop notification if auto-drop actually happens (email and it’s noted in their dashboard in the month it happened, so initially in the “now” area and later in that month in the history).
  • You can pledge unless it would immediately trigger an auto-drop. (However, pledging might immediately trigger the warning notification.)

Post-MVP:

  • TBD, and let’s not spend more time focusing on it right now.
19

Again, I’ll defer to @chreekat to set the policy for the code, but from my view, the random-drop adds unnecessary complexity to the code, and I don’t think dev’s should have to accept that at this time unless they are fine with it.

The calculation is then repeated since the patron count changed, and any additional auto-drops are triggered

Here’s why it’s so extra complex with the randomness. So:

  1. Given the rare case where multiple patrons are at their budget limit
  2. One pledge to one project puts all those patrons over
  3. If the random drop from one patron reduces a different project which is not also a project of the other patrons, then it leaves the other patrons over-budget still and thus requires all this extra repeating of the calculation until we’re sure nobody is over-budget.

Here’s the screwiest case:

  • 20 patrons at budget-limit, all pledged to project A and several others which are all distinct among all the patrons
  • The random drop happens to drop projects except A from the first 19 over-budget patrons
  • The 20th patron randomly drops project A.
  • Now all the other patrons have room to fit in all their dropped projects without being over-budget (they could have not had any drops).

Sure, this all happens when they are close enough that dropping is likely anyway. But in this instant, we’re talking about 20 rounds of calculations with 20 patrons getting notifications, and 19 of them come back to see that they are allowed to manually pledge back the exact project that was dropped for them and feel confused about why they were dropped.

Also, from the projects’ perspectives on UX, there’s a level to where we are asking projects to understand that there’s some degree of trade-offs between projects (popular projects can eat budgets and leave less for others…), but I think it gets worse to allow this case: “wait, I had X patrons, but now I’ve lost patrons just because other people (not my patrons) pledged to some other project??” (we’d never see a situation where a successful Kickstarter project causes another Kickstarter project to fail, so anything in that direction is already uncomfortable, and I suggest we minimize that effect other than the basic concept of system-wide budgets at all).

There’s so many interactions when we allow this more complex dropping process and so much increase in calculation and code complexity by having drops that don’t affect the project that got the new pledge.

To put it one last way:

If we always drop the same project that got the pledge, the code tests are extremely simple. It’s always one pledge, one drop, same project. Done. Never a need to check for other patrons still being over-budget. The first drop is all that’s ever needed.

If we drop project B after a pledge comes to project A, there’s no guarantee about whether or not there are other patrons over-budget still, so there needs to be all these extra calculations and tests etc.

Last thing I’ll say on this: having made the above points clearly, if @msiep wants the UX to allow any sort of scenario where pledge to A results in a drop to B, that’s his decision on design. But this is a case where @chreekat needs to be able to veto this. So, if @chreekat wants to go with @msiep’s design, fine. But @chreekat needs to hold the veto here, and I encourage him not to accept what seems to me to be a much bigger code burden for what seems to be dubious value to me on the design (since it introduces real issues with UX as well, as I mention above).

Since this whole issue only happens at the edge-point of just going over-budget, the simplest implementation seems the best to me.

20

I didn’t mean random selection of project to drop, just random selection of patron if multiple patrons in a given project go into the auto-drop situation at the same time.

I agree with the idea that an auto-drop is only triggered by an increase in patrons to that same project.

21

…but looking back I realize although that wasn’t what I meant it was what I wrote! Ooops!

22

Here’s my corrected proposal, since I didn’t mean to still propose random selection of which project to drop. Thanks for pointing that out @wolftune:

MVP:

  • “Auto-drop” (no concept of “suspended”) of a patron’s pledge to a project occurs immediately if their “if crowdmatching were done now” scenario would exceed their limit as a result of an increase in patron count to that project.
  • Carry over from previous months will never trigger auto-drop; if necessary it will be carried over again until it is paid off.
  • If the auto-drop conditions apply to multiple patrons of the same project at the same time, one is selected at random for auto-drop.
  • If the auto-drop condition for a patron is triggered by multiple projects that the patron supports increasing at the same time, then one project is auto-dropped at a time, in random order, until the patron is within their limit.
  • Patrons receive a warning notification if < $threshold away from their limit (via email and on website).
  • Patrons receive an auto-drop notification if auto-drop actually happens (email and it’s noted in their dashboard in the month it happened, so initially in the “now” area and later in that month in the history).
  • You can pledge unless it would immediately trigger an auto-drop. (However, pledging might immediately trigger the warning notification.)

Post-MVP:

  • TBD, and let’s not spend more time focusing on it right now.
23

Okay, but:

if we keep always the auto-drop to the same project that had an increase in patrons, then there’s never a case where you need to repeat the process for multiple patrons. One new pledge, one random patron dropped, now all other patrons that would have been above their budget are back to within their budget.

So, it’s always one-patron dropped (at most) for one-new-pledge.

The calculation is then repeated…

That can be omitted.

ADDENDUM:

If the auto-drop condition for a patron is triggered by multiple projects that the patron supports increasing at the same time

Okay, this actually brings up when to do the calculation. The whole idea of multiple etc. can only happen if we allow some period of time where multiple pledges take place prior to the auto-dropping.

If we do a single instantaneous drop along with any instantaneous single pledge, then there’s never multiple anything other than the possibility (albeit very rare) of multiple patrons such that we have to randomly choose one to be the dropped one.

So, if @chreekat decides that we only do dropping on some schedule instead of instantly, then various concerns like that come up. If he thinks all instantaneous is fine, then it’s simpler, and there cannot be cases where a patron has multiple projects over-budget at once.

24

I’ve removed it.

I think we’re in defer-to-@chreekat territory here. I’m not sure whether in a scaled up scenario with lots of users it would be possible to do the calculation as often as we might ideally wish to, i.e. after every single change in patron count to any project. Anyway, I look forward to @chreekat’s comments.

1 Appreciation
25

Apologies for phone brevity:

A pledge and any auto drop will happen in the same atomic, isolated transaction. This guarantees that the number of auto drops will always be zero or one.

I recommend splitting threshold warnings into a separate work item/user story. This will be something that happens to multiple patrons at the same time, and it may or may not happen in the same atomic pledge transaction. I think it’s fine for alpha, it’ll just take more time than the auto drop piece.

26

Throwing in my +1 to this. Although I think that the version with suspending/over budget is ultimately superior (I don’t like the case where someone joining and immediately leaving causes me to drop and not re-pledge), it adds a significant amount of complexity, which we don’t need for MVP.

Also +1

Unless anyone else has objections, I suggest @msiep move ahead with whatever the next step is here (wireframes/mockups? just a list of specs to hand to dev?).

27

For the record, the following proclamation is not set in stone for all time:

That decision has pros and cons, and we can adapt it to our needs. Just a note for future iterations.

1 Appreciation
28

So, I’ve been thinking quite a bit about this entire issue, and I think the very concept of dropping pledges due to going over budget of some master budget is a bad idea. As a project team member, it’s going to add to the chaos of budgeting what your income is going to be, AND, you are potentially getting punished for recruiting more supporters! As a supporter of a project, your agency and control over your pledges are more complicated, and you now have to ‘pick favourites’ out of your projects. As a mechanism, it adds complexity to the code and the crowdmatch system. Negative-Negative-Negative.

My simpler suggestion: Have a limit per project, do not have a master limit per account.

If I pledge to a project, and I understand that it may eventually increase, I’m accepting that potential risk with my initial pledge. I’m committed. With $0.001 as the base pledge, you would need 5000 supporters to hit $5.

There are only 28 with more than 5000.:neutral_face:

There are currently only 434 patreon creators with more than 1000 supporters.
Source: https://graphtreon.com/patreon-stats

With a $5 limit:
Let’s say I commit to 10 projects. That means I’ve committed potentially to $50/month.

One project gets super popular, and reaches 2000 supporters. So, $2.
The rest only reach a few hundred each. So, a $0.50 or so each.
I’m looking at maybe $5 a month.

Even if you double the scenario to 20 supported projects, it’s still well within the original $10/month limit we have now.

I vote against any sort of un-pledging mechanism that is not manually caused by a supporter themselves.

29

I was thinking about this as I lay in bed this morning, 1.5 hours before my alarm went off…

I think this catches the heart of the matter:

Right now, here’s how a patron would actually break their budget:

  1. They pledge to Snowdrift.
  2. ~10,000 other people also pledge to Snowdrift.
  3. Everyone’s pledge value becomes $10.
  4. No new patrons can join, since the limit is fixed and there is only one project.
  5. The project receives a fixed $100,000/month.

I think this shows that at the very least, auto-dropping is post-alpha. (I’m using alpha to mean “the platform is functional for one project, snowdrift.coop”. I can’t recall if MVP is “alpha” or something else.)

It also shows it’s a ludicrously unlikely position to be in.

Even post-alpha, in a happy place where there are 10 projects each with 1500 patrons (mostly overlapping), I’m also concerned about the experience of pledging to a project, only to see no difference in pledge value or monthly project donations, since my only impact was booting out one of the at-limit patrons. But that can be addressed when the matter arises.

30

@CANAWEN for what it’s worth, per-project limits have been discussed (some might say “discussed to death”) on different fora at different times. Hopefully someone can point you to previous discussions, but I believe the consensus was that it might not be a terrible idea for post-mvp, but it also might considerably complicate the UI. I think it’s a discussion for a different time.

How do per-project budgets alleviate these problems? It sounds like all you’re really suggesting is “no limits whatsoever,” since a $5 limit for one project is effectively infinity dollars. I agree with that, but the same is true for a master budget!

1 Appreciation
31

They’re in the mailing list archives, but I had trouble finding them. There is some relevant information on the wiki, if you haven’t read that yet:

https://wiki.snowdrift.coop/about/mechanism#budgets
https://wiki.snowdrift.coop/about/limits

32

The easiest way to understand the situation (and maybe we need to do better at communicating this and/or designing to give the right effect):

We don’t want any budget cap. We want everyone who can to donate all they can to public goods and totally change the global economy and power balances. The existence of a budget at all is purely because most people are not okay with a truly-open-ended obligation (and many have real points where they can’t give any more).

The optimal theoretical scenario: you pledge, projects grow, we’re changing the world, all good, you manually drop a pledge if (A) you literally can’t afford it any more or (B) you don’t think the project deserves it (they aren’t using their income effectively in your view) — at no point do formally set budgets even come into play here.

Think of the system-wide budget as nothing more than a guaranteed cap so that people feel okay pledging in the first place. We don’t want people to stick to that budget if they can afford more. We want them to increase their budget continually. We’d love if people just started with a $500 budget if they knew they could afford it and then just manually monitor stuff to make sure they’re happy with the crowdmatching progress.

The budget cap is a hard point where we will ask you to increase your budget and never automatically charge you more. It has little to do with per-project issues or which project gets dropped etc. (we just have to have something technically in place to make the budget cap function).

It’s like if you have a credit card where, just to be safe, you set it to require some extra verification if the balance ever goes beyond X. It’s not actually the way to budget all your categories in life, it’s just a protection against some unexpected crazy high balance. You expect to never hit it, and if you hit it intentionally and want to spend the money, you’ll approve going beyond the cap.

I certainly would like to reiterate the above to @msiep so design keeps this in mind. We want the budget to be used to assure people of their basic control, that they can’t be charged some crazy amount. We don’t want people focused on the game of the system being about fitting projects into a set budget (that would be a zero-sum game, and we actually want an expanding budget for public goods).

1 Appreciation
33

This particular bit seems a misunderstanding. Patrons hitting the budget cap (and not increasing their budget as we wish) doesn’t cause volatility in project income. Almost the opposite: it just causes income to just stabilize instead of grow more. And recruiting more patrons when people are at their budget is merely ineffective rather than punishing.

So, project with 10,000 patrons at their budget cap, 500 new patrons join (at a higher budget, so they stay in), the project ends up just still at 10,000. The new patrons just replace the dropped ones. The project doesn’t lose income.

And, to reiterate what I wrote above: we don’t want patrons to just drop and stay in their budget. We want them to say “okay” to our ask that they approve a higher budget, since they see that it’s worth it and they want to keep the project growing.

34

I’d add, this is actually a net positive, not a net neutral, because the 500 new patrons have a higher budget, so if more people join in the future, these new patrons won’t drop immediately.

35

I view any patrons getting dropped not of their own accord as a negative. I understand that projects won’t see a drop in funding, as the new patron will essentially ‘swap’ with the dropped one, but if more people want to support what they are doing, patrons getting dropped and swapped out for ones that can afford more means that there is support being left on the table. Sure, they are potentially getting more money in the future, but the person who was dropped is one less person that could still be supporting the project.

1 Appreciation
37

It see your framing of our mutual concerns [footnote intended here] as quite useful feedback. I hope @msiep and @mray will consider this in design work.

[I wish this were a footnote]: (we seem, from what I can tell near-100% agreement about values and ideals, not only broadly but in how we wish to see the system working if we could omnipotently make everything happen as we desire)

I would love to see a design that addressed all of your concerns without somehow turning away the subset of potential patrons who feel already a bit unsure about the loss of control about donating exactly the amount they want (hesitant to turn over any control to the cooperative crowdmatching process) and so who won’t tolerate the burden of staying in the crowdmatching until they manually drop out (even if we give all sorts of due notices to help them with that manual process).

It may seem that we could launch alpha with no budget cap at all (certainly people who are hesitant won’t pledge, others will, we see how it goes, pivot from there), but we’ve gotten too much push-back already; i.e. it’s clear that a large portion (not all though) of folks care about the assurance of having a hard budget cap.

The original design was authorizing a total donation amount (not monthly but total), so like:

  • I’m authorizing a one-time $100 for the system
  • However long it takes to reach that, once I get close, I want notice
  • I can manually authorize new funds if I want to stay in

This captures the way I (slightly) prefer everything to work, but some people worry about the runaway crowdmatching and the idea that their $100 authorization gets used up in one or two months (and don’t see that as good, although I would be thrilled about it myself, we’d be in the changing-the-world level of growth).

We’re now pretty invested in launching with the monthly-budget approach, but if at any point @msiep were convinced that the fixed-authorized-block-of-funds approach were superior enough, we could pivot to that (or even try that as an alternate option and see which different patrons prefer… both approaches could exist side-by-side in the same crowdmatching otherwise).