[Not sure if this is the best way to reply to this, sorry]
Count me in favor of budgeting so long as it's optional: if the feature is sufficiently tucked away and not advertised (except maybe a "what if I'm poor?" FAQ) it will only be used by those who need it. And for everyone else, we should consider a passive version of this, where you receive alerts rather than a hard cap - so for example, you get an email like: "hey, you asked us to let you know when your monthly payment increases by more than [some configurable amount], and this month it will be $XX more. If that's cool with you, simply ignore this email. Otherwise, log in now/click here to change your contributions." You'd get this email a bit before the payment so you have plenty of time to act, and that should certainly suffice to make many people comfortable getting started, since we're used to this setup with other things (subscription free trials, credit card payments, etc). This is of course in addition to the option of a hard budget. It might also help to add in a generated list of the projects that caused much of the increase (in a positive light, like "this +$5 will be used to match the increased support for project xxx and xxx!"). Speaking of hard caps, (and since I'm a fan of things continuing to work when you haven't been online in a while,) the choosing of projects to drop upon hitting a cap should be passive IMHO, not active - rather than saying "hey you've hit a limit and we need you to pick projects to drop now", imagine the live list of supported projects being perpetually reorderable: as you go along you always rearrange them such that when the limit is reached, the projects at the bottom of the list get dropped (as needed) by default and of course notifying the patron of what happened. Again, this is so that things keep chugging along when the patron is not around. Also: When the monthly payout goes *down*, it may prove rewarding to encourage the patron with the budgeting option to sort of "roll over" the difference towards future payouts. Food for thought From: Stephen Michel Sent: Friday, May 20, 16:52 Subject: [Snowdrift-design] [non MVP food for thought] Fwd: per-projectbudgets To: Design discussion for Snowdrift.coop This is an excerpt from the conversation Aaron & I had. It was separate initially because it's not MVP but this is now fairly short and has IMO the most interesting points. -- Email Policy: http://stephenmichel.me/email ---------- Forwarded message ---------- From: Aaron Wolf <aa...@snowdrift.coop> Subject: Re: Stuff I cut from the design list thread NNTR Date: Fri, 20 May 2016 13:19:30 -0400 To: Stephen Michel <stephen.mic...@tufts.edu> On 05/20/2016 08:26 AM, Stephen Michel wrote: On Fri, May 20, 2016 at 9:46 AM, Aaron Wolf <aa...@snowdrift.coop> wrote: On 05/20/2016 06:02 AM, Stephen Michel wrote: If you always increase your budget as needed, you're not really budgeting, so that's trivially true. The point is that each time you hit your per-account budget, you need to decide which project you would drop if you decide not to increase --O(n) in the number of projects--, and then decide whether to increase or drop-- O(1). With per-project budgeting, you've essentially made the first decision once, in advance, so you don't need to make it over and over again: the one you would drop is the one that's currently hitting it's cap. The only reason there's a cap is because that's a fundamental need for people to feel comfortable trying the system. It would be totally unreasonable for us to charge people as though they didn't have budgets. We RESPECT that people have budgets. It's not something we want in terms of our mission though!! I think there's a second reason here, too: the reality is that some people are on strict budgets -- but they want to help out anyway. Budgeting is a necessity to enable their participation. Yes, participation is a goal in and of itself, so that's valid. But it's secondary to funding FLO, as in if funding FLO versus participation are in *conflict*, Snowdrift.coop would aim for funding *if* no other values were compromised. If two options were equal for funding and one was more participation, we'd absolutely go with that. This is why I *support* the option of adding budget categories (e.g. "graphics software" vs "music" vs "research vs "Firefox") that provide options for patrons to set up their own budgeting. It's just definitely long past MVP (especially since nobody early on will be hitting budget limits because that will only come after we get enough patrons anyway. As you point out that does come with a cost of making budgeting a bigger focus for the people who we don't want to budget. Maybe that's a cost we're not willing to pay, or maybe there's another solution that doesn't incur that cost. I think the solution is to make budgeting an optional feature. But I think this is something we can discuss once we are launched and have data and research, and then Michael and Robert will have definite insights here too. (feel free to summarize this aspect of our conversation (your misunderstanding if you accept that) in a summary post to the list clarifying the view you hold now after this) I'm going to reply there soon, just didn't have time at a computer when I woke this morning. If you hit your budget overall and refuse to increase, you can choose which projects to drop, which is the same effect in the end as per-project budget. It's actually an algorithms / efficiency / optimization problem, to reduce the number of individual decision points you need to make -- either way you're making the same decisions, it's a matter of how many times you need to repeat the action of making those decisions. That's stuff that needs post-launch real-world data. Data would be helpful, yes. I don't know I'd say it's *required* for the initial design. But I'm nitpicking; we'll have a chance to get data and iterate later. Yeah, we can't require initial data, but that's why we have a design already: the system-wide budget (whether one-time or recurring, still to be decided there).
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design