Re: [Discuss] Pricing experiments & launch timeframe

[Dave Crossland]

Could the project sooner bootstrap itself with a mostly manual, spreadsheet
based calculation?
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] Pricing experiments & launch timeframe

[Peter Harpending]

On Tue, Oct 20, 2015 at 02:57:07PM -0200, Dave Crossland wrote:
> Okay cool - I see all the activity here, the sprints thread etc, but hadn't
> got a good sense of timing. No pressure :)

"Sprint", given the average physical fitness of a programmer, is akin to
everyone else's "light jog".

In all seriousness, I don't see us having a functional site until at
least summer of 2016, if that. We'd all like to see it come sooner, but
that's not going to happen without a lot of money coming in to hire
dedicated developers.

Peter Harpending


pgpU8A6rFFgEK.pgp
Description: PGP signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

[Stephen Michel]

On Tue, Oct 20, 2015 at 2:04 PM, Aaron Wolf  
wrote:



On 10/20/2015 10:09 AM, Stephen Michel wrote:

 !IMPORTANT!
 First: I propose we set a Design Freeze Deadline of next MONDAY, 
OCT 26

 for the mechanism. After that date, the design shall be locked in.


I agree with all these items.


I'm going to go ahead and update the beta-sprint wiki page with this 
date, assuming nobody else objects.



 Therefore, I propose the following:

 Show 4 donation levels.


I *like* the familiar idea of a few simple donation levels in 
principle.



 1. Minimum. Currently $1 per 1000 users.
 2. Average. This shall be the default / recommended. It is 
completely
 clear how we came to it, is not artificially manipulated (except 
for the
 first user) and provides a higher-than-minimum donation level to 
help

 projects get off the ground.


It's not clear to me whether pledging today's average is a set pledge 
at
that level or if it will adjust itself automatically to follow 
whatever
is the average going forward. That confusion itself leads to weird 
issues.


It would be today's average, and not automatically follow the running 
average. 'Follow the average' introduces too much complexity, I think.


I also think your issue has to do with this specific mockup (which is 
this way because it's on a white board), not with the idea in general. 
I'd image a final product would look more like one of these:


/-\
|  **$5 per 1000**  |
| (current average) |
\-/

/---\
| Recommended (?) |
|   **$5 per 1000**   |
\---/

On mouseover: (?) Current average donation.


I don't mind the idea of showing, "the current average is 0.5¢ per
patron" or something and having that as an option as long as the 
option

is labeled with the number clearly as a fixed pledge.

 3. Double the average. Provides an option for generous donors 
(rather

 than forcing them to decide on a value themselves).


Not sure about the "double" idea.


It's just filling in for the idea of some higher donation value. double 
seemed reasonable in the context of this mockup. Just to re-iterate: 
I'm pitching an idea, not a final product. All these little details can 
be modified as we're implementing,


 4. User-entered. Must be minimum or higher (duh). Provides an 
option for
 *extra* generous donors, or those who wish to donate less but not 
the

 minimum.

 Here's a whiteboard sketch I drew of how this might look. I *really*
 don't think this is unduly complicated.

 https://img.bi/#/818IWCe!tXPyBZZ4M1n2oqQeZNDSgAtSgOzD44fyGhFBFW6u

 ~Stephen


So, overall, I think a few options like this is both ideal in 
principle

and is familiar. However, I see the point that because this is a new
system, people will have very poor sense of the ramification of each
level. I could imagine people entering $1 per patron and then running
out of funds quickly. I think it's *okay* to risk some confusion while
we clearly state that this is beta, things are in flux, we may adapt 
as

we go. I think that within the core idea, we *can* launch without
getting this perfect as long as we make it clear that things are not
fully pinned down.

That said, I think there's some sense to perhaps making this less
confusing by just offering a few set levels without an arbitrary
open-ended box, and skipping the "average" thing.


The average is there in accordance with premise 5: All things equal, 
we'd prefer to allow the mechanism to function naturally rather than 
with our intervention.


We don't know exactly what will end up making sense as a donation level 
for a given project. What if it turns out project A is really valuable 
but only to a niche audience, so the optimal situation is a group of 
1000 people giving 10 cents per patron. It would be kind of silly if we 
only offered donations at a level of .1, .2, and .5 cents per patron. A 
solution that relies on the average (an average solution, heh) works 
regardless of how a project's support base turns out. And of course 
we'll always have the minimum there so it's not like the average should 
be restrictive if it's high.


I also highly suspect that I and other members will want to make a 
large donation to start with to help the project get off the ground 
faster and then lessen it as the community grows and that level of 
support is no longer needed (or sustainable). And I know that runs 
counter to the entire idea of quadratic growth, but that's a 
conversation for a different thread.


An open box like that allows for, say, a company to donate using the 
same mechanism as an individual, rather than needing its own. It also 
allows for a weird situation like above, where someone less wealthy 
wanted to join in to a project with an absurdly high average donation, 
but without donating the minimum. Plus, it doesn't make sense to have 
an average box unless there's an easy way to affect the average, ie, by 
choosing your donation level.


I

Re: [Discuss] Sprints?

[Stephen Michel]

On Tue, Oct 20, 2015 at 4:22 PM, Bryan Richter  wrote:

On Mon, Oct 19, 2015 at 03:37:10PM -0400, Stephen Michel wrote:
On Mon, Oct 19, 2015 at 3:29 PM, Jason Harrer 


wrote:

  If we keep changing everything and second guessing and changing
  everything, we're never going to launch.

This is a really good point. How do people feel about setting up 
sprints /
(in)formal deadlines for feature discussion? Or just some 
procedure for
closing a topic for discussion, as we get closer to finishing 
the design

of our MVP / beta launch?


Honestly, so far I feel like we've just been educating a new batch of
volunteers about the existing decisions. Nothing much has changed
recently, has it?

What we desperately need, I think, is a firmer picture of which
decisions *have* been made.


Very much agreed. That was the idea behind the whole 'design freeze' 
thing: pick a date. After that date, the decision on said thing must be 
made. We'll update the relevant wiki page to reflect that decision, and 
now it's closed for discussion (except in extraordinary circumstanced) 
until it's actually been implemented.


Because we can spend an eternity continually educating new volunteers; 
at some point we need to stop rehashing the same arguments with new 
people, batten down the hatches, and work on implementation.
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] Sprints?

[Bryan Richter]

On Mon, Oct 19, 2015 at 03:37:10PM -0400, Stephen Michel wrote:
>On Mon, Oct 19, 2015 at 3:29 PM, Jason Harrer 
>wrote:
> 
>  If we keep changing everything and second guessing and changing
>  everything, we're never going to launch.
> 
>This is a really good point. How do people feel about setting up sprints /
>(in)formal deadlines for feature discussion? Or just some procedure for
>closing a topic for discussion, as we get closer to finishing the design
>of our MVP / beta launch?

Honestly, so far I feel like we've just been educating a new batch of
volunteers about the existing decisions. Nothing much has changed
recently, has it?

What we desperately need, I think, is a firmer picture of which
decisions *have* been made.


signature.asc
Description: Digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] Launch ready issues

[Bryan Richter]

On Mon, Oct 19, 2015 at 03:16:17PM -0700, Jonathan Roberts wrote:
>
>3)have all graphics and coding actually loaded (not sure this is the right
>term) on the live site so we can test for bugs.

This one is bigger than one might think. Will discuss more shortly,
probably on the dev mailing list.



signature.asc
Description: Digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

[Aaron Wolf]

On 10/20/2015 10:09 AM, Stephen Michel wrote:
> !IMPORTANT!
> First: I propose we set a Design Freeze Deadline of next MONDAY, OCT 26
> for the mechanism. After that date, the design shall be locked in.
> 
> ---
> 
> Second: I'm going to re-pitch my proposal:
> 
> I hold these to be self-evident. If you agree with me, I don't see what
> your objection might be to this proposal. If you disagree, well, this
> list makes it easy to say exactly where you disagree.
> 
> 1. People are not confused by different donation levels. They may even
> expect them. Ex:
> 
> https://secure.actblue.com/contribute/page/demanding
> https://elementary.io/
> 
> 2. Some people would like to donate more.
> 
> 3. "Donate X per patron" is not a hard concept to understand.
> 
> 4. We do not want to unnecessarily handicap ourselves in getting off the
> ground (ie, by denying generous patrons the ability to donate more).
> 
> 4a. We do not want to use sleazy tactics to get people to donate more.
> 
> 5. All things equal, we'd prefer to allow the mechanism to function
> naturally rather than with our intervention.
> 

I agree with all these items.

> 
> 
> Therefore, I propose the following:
> 
> Show 4 donation levels.

I *like* the familiar idea of a few simple donation levels in principle.

> 1. Minimum. Currently $1 per 1000 users.
> 2. Average. This shall be the default / recommended. It is completely
> clear how we came to it, is not artificially manipulated (except for the
> first user) and provides a higher-than-minimum donation level to help
> projects get off the ground.

It's not clear to me whether pledging today's average is a set pledge at
that level or if it will adjust itself automatically to follow whatever
is the average going forward. That confusion itself leads to weird issues.

I don't mind the idea of showing, "the current average is 0.5¢ per
patron" or something and having that as an option as long as the option
is labeled with the number clearly as a fixed pledge.

> 3. Double the average. Provides an option for generous donors (rather
> than forcing them to decide on a value themselves).

Not sure about the "double" idea.

> 4. User-entered. Must be minimum or higher (duh). Provides an option for
> *extra* generous donors, or those who wish to donate less but not the
> minimum.
> 
> Here's a whiteboard sketch I drew of how this might look. I *really*
> don't think this is unduly complicated.
> 
> https://img.bi/#/818IWCe!tXPyBZZ4M1n2oqQeZNDSgAtSgOzD44fyGhFBFW6u
> 
> ~Stephen

So, overall, I think a few options like this is both ideal in principle
and is familiar. However, I see the point that because this is a new
system, people will have very poor sense of the ramification of each
level. I could imagine people entering $1 per patron and then running
out of funds quickly. I think it's *okay* to risk some confusion while
we clearly state that this is beta, things are in flux, we may adapt as
we go. I think that within the core idea, we *can* launch without
getting this perfect as long as we make it clear that things are not
fully pinned down.

That said, I think there's some sense to perhaps making this less
confusing by just offering a few set levels without an arbitrary
open-ended box, and skipping the "average" thing.

-- 
Aaron Wolf Snowdrift.coop 
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

[Stephen Michel]

!IMPORTANT!
First: I propose we set a Design Freeze Deadline of next MONDAY, OCT 26 
for the mechanism. After that date, the design shall be locked in.


---

Second: I'm going to re-pitch my proposal:

I hold these to be self-evident. If you agree with me, I don't see what 
your objection might be to this proposal. If you disagree, well, this 
list makes it easy to say exactly where you disagree.


1. People are not confused by different donation levels. They may even 
expect them. Ex:


https://secure.actblue.com/contribute/page/demanding
https://elementary.io/

2. Some people would like to donate more.

3. "Donate X per patron" is not a hard concept to understand.

4. We do not want to unnecessarily handicap ourselves in getting off 
the ground (ie, by denying generous patrons the ability to donate more).


4a. We do not want to use sleazy tactics to get people to donate more.

5. All things equal, we'd prefer to allow the mechanism to function 
naturally rather than with our intervention.




Therefore, I propose the following:

Show 4 donation levels.
1. Minimum. Currently $1 per 1000 users.
2. Average. This shall be the default / recommended. It is completely 
clear how we came to it, is not artificially manipulated (except for 
the first user) and provides a higher-than-minimum donation level to 
help projects get off the ground.
3. Double the average. Provides an option for generous donors (rather 
than forcing them to decide on a value themselves).
4. User-entered. Must be minimum or higher (duh). Provides an option 
for *extra* generous donors, or those who wish to donate less but not 
the minimum.


Here's a whiteboard sketch I drew of how this might look. I *really* 
don't think this is unduly complicated.


https://img.bi/#/818IWCe!tXPyBZZ4M1n2oqQeZNDSgAtSgOzD44fyGhFBFW6u

~Stephen
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] Pricing experiments & launch timeframe

[Dave Crossland]

On 20 October 2015 at 13:56, Aaron Wolf  wrote:

> > Trufont.github.io  is gathering steam to
> > replace fontforge as the leading libre font editor, so I'm looking at
> > ways to raise funds to accelerate development. Will snowdrift be ready
> > in November?
> >
>
> Obviously work is active, but I can't see us being operating in
> November. I would love to say otherwise, but there's so much to do still.
>
> Thanks for the thought, and the push. We will work to get this thing
> going ASAP!!
>

Okay cool - I see all the activity here, the sprints thread etc, but hadn't
got a good sense of timing. No pressure :)

I'll start with a 'supporting membership' scheme in November and see where
that goes, and try snowdrift when its ready :)
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] Pricing experiments & launch timeframe

[Aaron Wolf]

On 10/20/2015 06:01 AM, Dave Crossland wrote:
> Thought this was good:
> http://conversionxl.com/pricing-experiments-you-might-not-know-but-can-learn-from/
> 

I was already familiar with most of that, but good to see such a clear
compilation. I can't stand those dogmatic capitalist folks who argue
that the market makes all prices become this theoretical rational
perfect price. It really bugs me that the article and the comments all
think this stuff is great though. There's only tiny little admissions
here and there that all this manipulation may be ethically questionable.

I deal with these things as a private music teacher. I hate it. The
relation to me being the best teacher around has nothing to do with
whether I charge the most or how all the pricing works. It's all so sleazy.

Anyway, not sure if we should add more of these references, but I'm
going to post that link in the comments for consideration on this page:
https://snowdrift.coop/p/snowdrift/w/en/markets-and-prices

Perhaps others would like to read that and clean it up, add to it if it
seems warranted.


> Trufont.github.io  is gathering steam to
> replace fontforge as the leading libre font editor, so I'm looking at
> ways to raise funds to accelerate development. Will snowdrift be ready
> in November?
> 

Obviously work is active, but I can't see us being operating in
November. I would love to say otherwise, but there's so much to do still.

Thanks for the thought, and the push. We will work to get this thing
going ASAP!!

-- 
Aaron Wolf Snowdrift.coop 
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

[Aaron Wolf]

On 10/20/2015 12:39 AM, Jacob Chapman wrote:
> This is really good that we are discussing this, because it needs to be
> discussed. I think we all agree that it is best if we start out simple
> because it will be easier to explain and much more transparent.
> 
> I think the solutions that have been thought are really good and we will
> need to decide on something simple to start and then adjust to more
> complexity as the site gains more users.
> 
> I would just like to suggest another solution:
> 
> 1 pledge = minimum + minimum_matched (+ any extra the user wishes to donate)
> 

Anything that embraces the idea of bypassing the network effect and
matching, even as an extra comes across completely as giving up. It
sounds like us saying that we think the network effect is just a little
gimmick, most people can and should give unilaterally mainly. It muddies
the message and makes things much more complex. It makes it a less bold
push for people to accept the idea of democratic consensus and giving up
some of their control.

There's also a bunch of weird cognitive strategizing from anyone saying
"hmm, how much extra should I give beyond the matching pledge". If ever
(and I think should not be at launch), we offer any unilateral
donations, it shold be one-time tip function for people to make single
extra donation. We don't want people to feel tied to a complex system of
both unilateral and matched donations.

> That means that patrons can easily donate as much as they want. The
> extra that they donate is not matched and does not affect pledging. A
> pledge is a pledge. Every pledge is matched and it doesn't create a
> problem if people want to be really generous.
> 
> I don't believe that people who want to donate more than minimum are
> driven by the desire of being matched by 100s or 1000s of people. I
> believe that 99% of potential double-pledging will be from people
> receiving the money. (and I don't believe there are going to be many
> people who are greedy AND working on FLO projects at the same time).
> However, all of this is based on speculation so we really need to do
> testing.

I agree that people thinking about making duplicate accounts is
speculative and won't be common. However, I *do* think that people are
motivated by the matching but only as a means to the end. People are
*most* motivated by wanting to see the project succeed. In that respect,
they *do* like the idea of figuring out how to make that happen, and
getting *others* to donate more is one way.

> 
> Maybe patrons need to have the extra incentive of having more matching
> or maybe not, but this is simple to implement and allows us to more
> easily incorporate the formula [/w/en/formula] as we go.
> 
> I don't think we should design so much of the system based on preventing
> double-pledging. There are a lot of ways we can prevent it. But I really
> don't believe people will be motivated to turn their $6 into $18 for
> someone else when they can already turn their $3 into someone else's $9.
> Maybe I'm completely wrong, but I think we need to test it against the
> real world and then revise. I'm not saying that my idea is the right way
> to go (I have no evidence), but I am strongly suggesting that we choose
> something simple to begin with and then make it more complex later.
> 

I agree with simple-to-start, and even though I lean toward per-project
pledge levels, I *mostly* care about getting launched and will give
Robert deference for the design as long as the concerns have been
discussed, because that's his position as lead designer to make that
say. I agree that we can launch and adapt options later *despite* the
fact that some degree of entrenchment to the initial model will occur.

So, if we have a per-patron system-wide setting of pledge level, it's
not hard to later add the nuance of varying that per-project.



> On 10/20/2015 7:45 AM, Aaron Wolf wrote:
>>
>>
>> On 10/19/2015 03:40 PM, mray wrote:
>>>
>>>
>>> On 19.10.2015 17:47, Stephen Michel wrote:


 On Mon, Oct 19, 2015 at 11:27 AM, Aaron Wolf  wrote:
>
>
> On 10/19/2015 08:20 AM, Stephen Michel wrote:
>>  In short, I don't believe we actually need any change to the mechanism;
>>  we just need to lower the minimum and encourage donation at
>>  above-minimum levels.
>>
>>  We should do this by keeping in mind that *the average user will
>> tend to
>>  stick with the defaults.* Therefore, if we set the recommended pledge
>>  level above the minimum, so long as that pledge level is reasonable
>> (ie,
>>  easily within the user's budget), they will stick with that donation
>>  level. I propose the following. Note: numbers are rather arbitrary, I
>>  just wanted to give a concrete example/idea.
>>
>>  let n refer to the number of users.
>>
>>  - Lower the minimum contribution to $1 per 5000 users.
>
> There's no basis for you to speculate that this lower minimum makes any
>>

[Discuss] Pricing experiments & launch timeframe

[Dave Crossland]

Thought this was good:
http://conversionxl.com/pricing-experiments-you-might-not-know-but-can-learn-from/

Trufont.github.io is gathering steam to replace fontforge as the leading
libre font editor, so I'm looking at ways to raise funds to accelerate
development. Will snowdrift be ready in November?
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

[Discuss] Fwd: Valve price experiments

[Dave Crossland]

Another fine read on pricing

http://www.geekwire.com/2011/experiments-video-game-economics-valves-gabe-newell/
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

[Jacob Chapman]

This is really good that we are discussing this, because it needs to be
discussed. I think we all agree that it is best if we start out simple
because it will be easier to explain and much more transparent.

I think the solutions that have been thought are really good and we will
need to decide on something simple to start and then adjust to more
complexity as the site gains more users.

I would just like to suggest another solution:

1 pledge = minimum + minimum_matched (+ any extra the user wishes to donate)

That means that patrons can easily donate as much as they want. The
extra that they donate is not matched and does not affect pledging. A
pledge is a pledge. Every pledge is matched and it doesn't create a
problem if people want to be really generous.

I don't believe that people who want to donate more than minimum are
driven by the desire of being matched by 100s or 1000s of people. I
believe that 99% of potential double-pledging will be from people
receiving the money. (and I don't believe there are going to be many
people who are greedy AND working on FLO projects at the same time).
However, all of this is based on speculation so we really need to do
testing.

Maybe patrons need to have the extra incentive of having more matching
or maybe not, but this is simple to implement and allows us to more
easily incorporate the formula [/w/en/formula] as we go.

I don't think we should design so much of the system based on preventing
double-pledging. There are a lot of ways we can prevent it. But I really
don't believe people will be motivated to turn their $6 into $18 for
someone else when they can already turn their $3 into someone else's $9.
Maybe I'm completely wrong, but I think we need to test it against the
real world and then revise. I'm not saying that my idea is the right way
to go (I have no evidence), but I am strongly suggesting that we choose
something simple to begin with and then make it more complex later.

:)
Jacob

On 10/20/2015 7:45 AM, Aaron Wolf wrote:
> 
> 
> On 10/19/2015 03:40 PM, mray wrote:
>>
>>
>> On 19.10.2015 17:47, Stephen Michel wrote:
>>>
>>>
>>> On Mon, Oct 19, 2015 at 11:27 AM, Aaron Wolf  wrote:


 On 10/19/2015 08:20 AM, Stephen Michel wrote:
>  In short, I don't believe we actually need any change to the mechanism;
>  we just need to lower the minimum and encourage donation at
>  above-minimum levels.
>
>  We should do this by keeping in mind that *the average user will
> tend to
>  stick with the defaults.* Therefore, if we set the recommended pledge
>  level above the minimum, so long as that pledge level is reasonable
> (ie,
>  easily within the user's budget), they will stick with that donation
>  level. I propose the following. Note: numbers are rather arbitrary, I
>  just wanted to give a concrete example/idea.
>
>  let n refer to the number of users.
>
>  - Lower the minimum contribution to $1 per 5000 users.

 There's no basis for you to speculate that this lower minimum makes any
 sense. These types of changes are only sensible once we can operate and
 see how the numbers play out. Our current baseline is as good an
 appropriate guess and easier to calculate and explain.

 I think you need to read https://snowdrift.coop/p/snowdrift/w/en/limits
>>>
>>> I have read this.
>>>
>  - For small n (< 100), the recommended contribution is $1 per 1000
> users.
>  - For n <= 100, the recommended contribution is the average of other
>  users' contribution.

 We don't want to recommend people counteracting the network effect. That
 would mean a message to others that says "if you join, others will
 adjust their pledge downward and actually *not* match you really".
>>>
>>> There's very probably some phrasing improvements. However:
>>>
>>> 1. When you join, others will match you at the level they have selected,
>>> no matter what. The messaging should be:
>>>  - "If you join, current patrons will donate $X more."
>>>- This is a simple concept which everyone gets.
>>>  - "Future patrons will match you at a level they choose. We'll
>>> recommend they match you 1:1, so if you donate more/less, we'll
>>> recommend they match YOU more/less respectively.
>>>- This is slightly more complicated. Probably, this puts the idea
>>> outside the scope of our MVP. This is fine.
>>>
>- This is presented to the user as "match other users 1:1"
>- The user has an option to match at a different rate, but it's not
>  highlighted visually.
>  - If a user does opt to change their rate, the following message is
>  displayed:
>- "This will [increase/decrease] the recommended donation[!/.]"
>
>  Hopefully this allows for all of the following:
>  - A social incentive to donate more (increase the recommended
> donation).
>  - A way to donate less with a reasonable social "penalty."
>- if