On 05/19/2016 12:54 PM, Stephen Michel wrote: > 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: >
Please stop "fixing" things that we already fixed. We're working on an MVP here, not reconsidering everything over and over. We never ever ever say "there will be some safeguard" we always give a concrete answer that we already decided long ago: "you will set a budget for the system overall, it's not like we just have your credit card and charge whatever. If the pledge goes beyond your budget, you'll get a notification and the be able to choose whether to drop the pledge or adjust your budget." The only thing that is "there may be SOME x" is the "project so popular that many people can't afford to pledge" which has the answer of "we will be a success already if we get to where that is our problem, but we have ideas about the best ways to handle that. It's not a major problem though — people dropping out due to high pledge value is a natural self-correction to high pledge value. but read the limits wiki page for more thoughts" We have a HUGE list of problems that have not been answered at all. Please don't waste time reconsidering ones that are not in that list. > 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. No, nobody thinks this is fundamentally wrong. This is just the "wallet" approach, even if we actually charge in arrears. There's NOTHING wrong with absolute limit. People *obviously* can *change* their absolute limit by adding/authorizing more funds. This is the approach where some people feel the most control. It's fine. > 2. Patrons set a monthly budget for their account. This is just a subtle difference from number 1, and it's fine too. We do indeed need to pick the implementation of 1 or 2 here, and I'm okay with offering BOTH. I think it would be good to offer both and get feedback from there. It would not be that hard. People just choose to accept X as a total to play with or set a monthly budget limit. Both are easy to understand. > 3. Patrons set a monthly budget for each project. > This is something we already discussed in the discussion part of the limits page. It's comparable to multiple accounts in order to create separate budgets to buffer one project against another. It is screwy in various ways. It's not terrible, but it works against consensus and the idea of providing a budget overall. Number 3 here creates a huge extra variable for people to do something quite different from just pledging-or-not. Instead, they are starting to do all sorts of complex juggling of budget values for multiple projects. It's complex, harder to track… I don't want us to consider this for MVP or just-after MVP. Effectively, this does revisit the whole concept of "shares" in that it's part of trying to address the whole issue of wanting to really support some important project big time but not caring as much about some minor project etc. It's not crazy. But it's definitely complex. For initial use, we don't have to create per-project budgeting or per-category budgeting. People could just create two users and have them each budget different amounts. This is a more serious issue: not wanting people to game the system by creating many patrons accounts just to get matched more. But a certain amount of this isn't fatal. Anyway: https://snowdrift.coop/p/snowdrift/w/en/limits/c/1998 All that said, if we had the resources to research all these options and implement them all, I'm not opposed. But I oppose the idea of choosing number 3 alone and going with that first. It is definitely an alternate-maybe-later option, not acceptable as the initial only option (although for a one-project MVP it's the same) > 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. > This is speculation (that I think is also invalid). We have no basis to think that per-project budgeting will increase participation over system-wide budget. > --- > > (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. > This is would be an *extra* decision. If, under an account-wide budget, your total is enough to cover one projects' increase, then there's no decision to make. There's just a single decision to make when you hit your budget: drop some projects or increase your budget. In your per-project budget, there's far far more decisions to make as all sorts of projects hit their budget limits, and every time that happens you would still look at the values everything else has and consider the overall effect of this project budget change. So, per-project budget does *not* mean you are making one-project-only decisions, it means you get a better way to *lie to yourself* that you are doing that. In reality, you're aware of the overall effect and playing with that. The whole point of system-wide budget is that we're trying not only to think of each project as its own isolated thing. We're aiming to help everyone see things systematically. We need to coordinate to support the most deserving projects, we need to use the funds that go to proprietary and put them to FLO. We need to stop fragmenting our support to too many half-done things. Per-project budgeting fights against all these values and undermines *some* of the value of the whole Snowdrift.coop system > 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. > Right, that's an effect of the system overall, and per-project budgeting doesn't help here. > 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. > That's an extra variable that is going to also be *quite* VARYING. This is potentially *counter-productive* because showing people the end-game in game theory dilemmas results in strategic anti-cooperative thinking. https://snowdrift.coop/p/snowdrift/w/en/mechanism#flexibility-with-practical-limits We don't want to make people decide hard limits per project, we want the to give up some control to the cooperative process. They need to feel like "okay, I have a system-wide budget, but I'm willing to work with others to make a difference and see where things go". I, um, well, just read the link I just posted. > 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). > We want people to think that the potential funds are absolutely NOT set. They are all the potential patrons who have not yet joined who you are hoping will join AND the fact that people WILL adjust their budgets. The fact that budgets are adjustable means that showing an available pool is a lie. Besides, studies of traditional matching in non-profit fundraising show little improvement in when telling people that there's a certain pool of matching funds to capture or that their match is however many times over. The real huge impact comes when you go from unilateral donation to matching at all. Once you're matching, people don't really donate more because of the details of how much funds or how great the match is. In our case, the importance of the number of patrons is so people get a general sense of community size and support as well as understanding what it means for their donations. But it's not actually going to change participation levels to show the pool. In fact, it is likely to HURT participation by making people say "oh, there's only this limited pool, I'll let someone ELSE claim it". > --- > > (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)." > That's not unlike system-wide budgeting. And normal budgeting is not per-project. People budget $X for "groceries" not $X for Safeway and $Y for Shopmart. > 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. > That's not why people budget. Nobody budgets *in order* to get deals. People who do NO budgeting still look for deals. These are unrelated behaviors. The reason people budget is to keep in control of their *overall* resources. A budget system-wide for Snowdrift.coop is all they need. In the end, the point is that there could be expensive projects that matter a lot to a smaller number of people, and those people may want to still coordinate together in the Snowdrift.coop fashion but need to have donation levels much higher per-patron than a popular project supported by hundreds of thousands of people who donate only a bit each. Having a different budget limit for each project doesn't solve this issue at all. So, this topic isn't the core one that Michael was bringing up.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
