Please see https://git.snowdrift.coop/sd/design/issues/65 and let me know your thoughts.
Thanks,
Michael
The proposals seem a solid starting point to me. We can expect tweaks and pivots once the system is in use.
My only other thoughts are somewhat meta (none of the following is blocker to moving forward with that issue per se) and relate to the general limits stuff, reiterating some here:
- In the overall UX, we care that people understand that they are in or out of crowdmatching — that the negotiations around cooperation can’t work if they want their cake and eat it too (i.e. they want to match others, but only to a point)
- We want to communicate something about practical limits such as:
- Support the projects that most need your support and that you can afford, but make any and all use of public goods — i.e. don’t feel guilty ever about using all public goods, just do what you can to support those you care about most and that most need your support.
- If we reach the point where a project is fully funded, we’ve succeeded! When any projects actually hit that point, we can change the game to focus on just sustaining the project and less about crowdmatching to push funding growth (but we’re not focusing on that as we’re not there yet).
- If projects grow to high levels but still need further growth, we may offer other ways to stay in such as pledging to smaller sub-projects or reduced-frequency of crowdmatching participation (bimonthly, quarterly etc)
- We also want the right amount of encouragement that people increase their budgets (connecting to verifying that the projects deserve their continued support) without being too strong or too much pressure etc.
In short: we should do what we can to make people feel comfortable and supportive at this time, understanding some context when experiencing hitting their budget limit.
I’m not sure what exact words, charts, images, links etc. will best achieve these goals alongside the core operations…
“Suspended” status will automatically revert to active pledge status if (regardless of whether due to the patron’s actions or otherwise) the patron’s limit becomes sufficient to accommodate the higher of a 10% or 100-patron increase in the project’s patron count.
This all makes sense, but it does seem a little odd that I could be pledged to a project → new patron joins → I’m suspended → same new patron drops → I’m still suspended.
At the same time, it would be annoying and confusing to keep getting notifications about my pledge being dropped and reinstated.
Maybe there’s a middle ground where if I’m within the 10%/100-patron threshold of being dropped (let’s call it the danger zone), I get a single warning email at that point but then dropping the pledge doesn’t actually happen until the end of the month?
“Suspended” status will automatically convert to “unpledged” status if it persists continuously for 30 days.
Why not allow a pledge to stay suspended indefinitely? Following that line of reasoning, it could also be possible to add projects to a “wishlist” you would like to support automatically if they pass a certain threshold, although this is almost certainly outside mvp scope.
Although, this may require additional backend work since we’d need to track things like the order each patron joins in (although this is personally good for auditing purposes anyway).
I think this may be worth checking in to see what kind of solutions would be easier/harder to implement (note: I am not saying we should let “it’s more work” prevent us from implementing a better solution, just that it may be worth considering).
I might suggest splitting off pledge-dropping as an independent first step. Among all the actions listed, it alone requires no new backend components, and is entirely straightforward. (It does, however, rely on the nonexistent notifications component, but it would not be the first to do so.)
I have nothing against the other pieces; this is just a suggestion about chunking the task.
First thing I noticed is: it’s relevant once we have more than one project.
Might be good to clear this ahead of time to be prepared, but it is not urgent imho.
Second thing is: I’m still skeptical about adding this kind of extra complexity. In my eyes suspending optimizes towards spending most money as close as possible to your limit.
I’d propose to not make early optimizations and see how the system works with manual pledging only.
Questions coming to mind concernig the mechanism would be:
- Why would the project that “grew” in the last moment to hit the limit get suspended? - maybe another project grew much faster, and by sheer coincidence onther project actually hit the limit.
- Is there going to be a mechanism to suspend/unsuspend other projects - next to pledging? - I may want to move the “suspended” flag around.
I think this comment, combined with mine, raises a good point. We need to add a step between (a) writing user stories and (b) the rest of the pipeline. This extra step is where we prioritize and break down the list into understandable chunks. I won’t say any more about it here, but expect an email.
Thanks everyone for these helpful responses.
Interesting idea, though it would actually be more a question of pledging to that project automatically if (a) you increased your limit or (b) the target project and/or some of your active pledged projects lost enough patrons that it could now fit in your existing limit. I don’t think we want to put anything in that suggests anticipating or even hoping that projects will lose patrons, but I think having a way to flag projects I’m interested in but currently not pledged to (even if my current limit could accommodate them) is really worth considering. It would be kind of like a shopping cart. Definitely outside mvp scope, though, as you say.
In theory it could become relevant even with one project. But supposing our minimum limit were $5, we’d need 5,000 patrons for it to become relevant in practice, which I’m sure we won’t get until we have more than one project, so overall I totally agree.
Do you mean it would be better to design for patrons to be more motivated proactively to stay comfortably below their limit, by adjusting their pledges and/or increasing their limit? That makes a lot of sense to me. How about if instead of the “suspended” concept we just auto-drop if necessary but, in addition to appropriate notifications, their dashboard would show (until they told it not to) that they had been previously pledged to Project X but it got auto-dropped to respect their limit.
I think it’s going to necessarily be somewhat arbitrary. We have no way of knowing which project the patron would choose to drop, and we want to encourage patrons to control this themselves so auto-dropping rarely happens. Probably the most important thing is that it be a simple basis that patrons can easily understand. Maybe it would be best to make it explicitly random?
I think you’re getting at something similar to @smichel17 like having an option to have something like a “shopping cart” of projects I’m interested in but not currently pledged to? It could be a list of projects that you’re not currently pledged to, showing whether it’s one that was auto-dropped, one you manually dropped, or one you’ve never pledged to. You can add and remove items as you like, but when they’re auto-dropped they go into that list, and when you manually drop, you’re asked whether you’d like it to go into that list.
It shouldn’t happen at the same time for everyone, like the end of the month, because we need the crowd size at any one moment to be meaningful and stable. But if we use @mray’s proposal of not having a “suspended” concept but just an “auto-drop” concept then it makes perfect sense to send a warning email about being near your limit. If we decide to choose randomly which one to drop, the warning email saying that we’ll choose randomly would encourage people to take control I think.
(BTW this is my first time responding in Discourse, and I love how I can go through the thread and mark things to quote and then reply to it all in one go like this. Huge improvement over email threads!)
To summarize, what I propose now based on the above is:
MVP:
- Random “auto-drop” (no concept of “suspended”) occurring immediately if your “if crowdmatching were done now” scenario would exceed your limit (excluding carry over from previous months, which if necessary will be carried over again until it is paid off)
- Warning notification if <10% away from limit (email and website).
- Notification if auto-drop actually happens (email only for MVP).
- You can pledge unless it would immediately trigger an auto-drop. (However, pledging might immediately trigger the warning notification.)
Post-MVP:
- A list of projects you’re not pledged to, with auto-dropped projects auto-added to that list, option to add to that list when manually dropping a project, and option to add non-pledged projects to that list even if your limit doesn’t currently allow pledging to them. Ability to manually remove a project from the list.
Wolftune has explicitly required that if a patron pledges to project P, it can only ever cause other patrons to drop their pledges to the same project P. I think this makes sense for a number of reasons, so we should keep it. The question becomes, who gets dropped? Since three people could be over, but only one needs to be dropped to have the others go back under their limit. I honestly don’t know if it’s best to drop the last person who signed up, but it’s probably a good start. The notification could perhaps explicitly call out that they are dropped because they were the last person to join who has gone over their limit. (Could be enough to motivate a limit increase!)
What about the following?
- Send a warning email when the user is within
$thresholdof their limit. - If a project’s level increases such that one of its patrons is now over budget, their pledge becomes Over Budget.
- Tie gets broken by pledge date as propsed above.
-
Over Budget pledges don’t count towards the pledge total.
- Users with Over Budget pledges will also have a note on their dashboard, “Pledges over your budget limit will be dropped at the end of the month.”
- If someone drops from one of the projects the user is supporting such that the project now fits within the user’s budget, it is automatically reinstated, since it is no longer Over Budget (duh – this is why I’m calling it “Over Budget” instead of “suspended”).
- The user does not recieve any notification of pledges being suspended or reinstated; they should understand that while they are in the warning zone, this may happen at any time.
- At the end of the month, when payout happens, if a pledge is Over Budget, it gets dropped instead.
In this way:
- It is clear to the user that if they’re within the warning threshold (“Danger Zone”?) then their pledges may be dropped without warning.
- There is still a logical reason why a pledge would be dropped.
- It still feels somewhat “random” to the user, because they’re not sure which project will actually get the pledge that puts it over the limit.
- No weirdness if someone joins and then leaves a project.
- Pledge dropping happens at the same time as payout, so we can include it in the same notification about pledging.
- Uses plain vocabulary instead of a special word (suspended).
On the issue of which project gets dropped and then which patron:
Wolftune has explicitly required that if a patron pledges to project P
I set that after our discussion as the idea that it seemed to open crazy bags of worms to do otherwise. But please don’t treat this as my requirement. If the Website Circle decides that this requirement is wrong, it’s your domain to decide. I’m not placing a policy to limit this. I did start to bring it up though until I saw it already mentioned, so I do still think it’s a good way to easily do things.
drop the last person who signed up
I’d worry about the feeling of “I just pledged, and now I’m dropped…” being disappointing. But dropping the first patron isn’t ideal in that people with long history of pledging want to keep it up (but maybe they will be the most motivated to adjust / increase budget?)
Overall weak vote from me is to drop the oldest pledge among those now over-budget. This works as long as the re-pledge after adjustment (dropping other projects or adjusting budget) counts as a reset to newest for what counts as “oldest” for dropping (but we’d still want to honor the patron as being a patron since their initial older pledge time).
Awesome! Just noticed that too.
I like everything about what you propose for MVP.
As for the Post-MVP my concern is we are building a system to fill the plate higher than its rim. I think that is opposing our general interest.
Imho, too complicated.
As every projects “size” is in flux all the time I think it is impossible to come to a “sensible” solution, which is why I currently think we might just be open about following our goals: We drop projects based on their size: favoring bigger ones. More people think that is what should stay.
To clarify, what I am proposing is basically the same as @msiep’s original linked proposal, but calling it “Over Budget” instead of “suspended” and not requiring the buffer to automatically reinstate a pledge.
I don’t like a “favor bigger” rule. For one, we accept that there’s some natural (budget-related) moderating of the network effect. But mostly I think it’s too hard to have a good one-size-fits-all-cases rule.
I like the long-term ideas of more good tools for people to set their priorities. I like the idea of just letting them manually deal with this for now.
The reason for pledge-to-a-project-drops-pledge-from-same is more implementation: it certainly seems far easier to not have to bother doing extra evaluations of the other projects in deciding what to drop. Just “pledge only affects the same project” is a much simpler way to implement. Easiest thing to just have some rule for now and we move forward. Will defer to @chreekat still though about ease of implementation questions.
There will have to be one default behavior one way or another. Getting the most desired choice manually right from the start appears to be overkill interaction cost.
That would be one way to phrase it! I think “most peoples consent weighs most” meets our goals and is one sensible default – easily to be overriden manually.
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 <
$thresholdaway 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.
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:
- Given the rare case where multiple patrons are at their budget limit
- One pledge to one project puts all those patrons over
- 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.
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.