Thanks for getting the ball rolling on this conversation, Michael.
On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
<m...@techdesignpsych.com> wrote:
As discussed in a recent meeting (transcript in
https://tree.taiga.io/project/snowdrift/task/323), wolftune, mray,
me, and anyone else who wants to participate, need to discuss current
status and next steps to get the project page design sufficient for
MVP, and also the dashboard design
(https://tree.taiga.io/project/snowdrift/us/67).
mray: I think you have mockups of these which we could revisit as a
starting point? Anything else we should look at or think about
before actually meeting?
People's first question about the mechanism is ALWAYS "What prevents me
from suddenly getting a huge bill if there's influx of patrons?" Of
course there will be some safeguard in place to prevent this.
"Some safeguard" is pretty vague. Let's fix that. I see 3 options:
1. Patrons set an absolute limit, where we won't ever charge them more
than that, total.
- I anticipate everyone agrees that this is a bad option for us (or
any ongoing system). If it turns out I'm wrong, I'll elaborate then.
2. Patrons set a monthly budget for their account.
3. Patrons set a monthly budget for each project.
I think #3 is the best. Here's why:
---
(A) It can be set at the time of pledging
This allows people to be more comfortable when pledging, potentially
increasing participation.
---
(B) Post-MVP, it's a simpler decision (albeit one that's made more
often)
When I run over my budget, I have to decide whether to increase it or
drop a project. In the per-project case, I need to make that decision
for one project only. For an account-wide budget, I need to make that
decision for every project I'm supporting.
When I'm pledging to a new project, the account-wide case forces me to
consider whether I'd rather put my budget towards projects I'm already
supporting, since projects compete against each other for a share of my
budget.
This disincentives to supporting multiple projects; that's NOT the type
of "rule of the game" we want to be creating. It also puts the 'Pledge'
action behind a complex decision. This will discourage people from
pledging regardless of how the incentives align.
---
(C) It reinforces the idea of matching
For example, it would allow us to show a visualization of a project's
current funding level and also the pool of money available for matching
as others join a project.
We could also include a visualization that shows how increasing your
budget cap bolsters that pool of available funds (and therefore
provides a stronger incentive for others to pledge).
---
(D) It's more like normal budgeting
"I'm setting aside $X per month for this project (even if I may not
actually give all of that this month)."
The closest comparison I can think of to an account-wide budget is a
shopping budget, where you're buying the same stuff each time, and the
prices for individual things might change but your budget won't. Unlike
shopping, though, Snowdrift is a donation, not a transaction, so I'm
not (or shouldn't be) concerned with getting the best deal ("sales") --
ie, only support projects when their pledge level drops; when they
start losing patrons.
_______________________________________________
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design
