Re: [Snowdrift-design] [non MVP food for thought] Fwd: per-project budgets

[cnnr_dhrty]

[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 

Subject: Re: Stuff I cut from the design list thread NNTR

Date: Fri, 20 May 2016 13:19:30 -0400

To: Stephen Michel 


On 05/20/2016 08:26 AM, Stephen Michel wrote: 


On Fri, May 20, 2016 at 9:46 AM, Aaron Wolf  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 

[Snowdrift-design] [non MVP food for thought] Fwd: per-project budgets

[Stephen Michel]

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 
Subject: Re: Stuff I cut from the design list thread NNTR
Date: Fri, 20 May 2016 13:19:30 -0400
To: Stephen Michel 

On 05/20/2016 08:26 AM, Stephen Michel wrote:
 On Fri, May 20, 2016 at 9:46 AM, Aaron Wolf  
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).




signature.asc
Description: PGP signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design