Please see https://git.snowdrift.coop/sd/design/issues/65 and let me know your thoughts.
Please see https://git.snowdrift.coop/sd/design/issues/65 and let me know your thoughts.
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 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:
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:
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!)
@chreekat sounds good to me.
What about the following?
$thresholdof their limit.
In this way:
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.
$thresholdaway from their limit (via email and on website).
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:
Here’s the screwiest case:
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.