I may agree with you; I haven't quite decided yet. I'm going to continue to argue until I'm convinced one way or the other.

On Wed, Oct 21, 2015 at 6:36 AM, mray <m...@mray.de> wrote:


On 20.10.2015 19:09, 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/

This is comparing apples with oranges.
Snowdrift changes the donation level with each new donor already.

Hmm. In one sense you're completely right. Snowdrift is a unique mechanism and therefore need not necessarily mimic existing systems. So I agree that this should not be used as a *justification* to add different levels. ie, let's scrap the part about people's expectations -- we don't need to follow them.

That doesn't change what people's experiences have been, so I think the point stands. Particularly, I included this point to preempt any cries of "but different donation levels increases complexity too much," and I believe these examples serve as an effective counterargument to that.


 2. Some people would like to donate more.


I agree, but then again 0.1¢ isn't really much when there are 93 donors.

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

I agree.


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


I disagree.
We absolutely want to handicap ourselves "in a way":
Picture a new project with about 100 donors.
The average match factor is under 1¢.
Most donors *DO* want to pay more - right?
We effectively deny "generous" patrons to pay *WAY* more than they do in that case. It just begs the question of what is "generous" and that hard
to pin down.
Where would you draw the line?

You can make the same argument in the other direction. When a project has millions of donors, we deny poor potential patrons a way to contribute meaningfully. However, some people may only be interested in donating a fraction of a cent, to game the system. Where do we draw the line? Right now it's at $1/1kP. As per point 5, ideally we'd prefer for the market to decide on a minimum donation. However, I cannot think of an effective way to do this, so we accept a certain level of intervention. We could implement a safeguard of, "if any user wishes to donate at a lower-than-minimum rate, so long as their absolute donation remains above $X per month, they shall retain patron status. However, there's no effective parallel on the upper end.

I think perhaps what you're getting at is another goal:

4b. We do not want to handicap a sustainable funding model (ie, by implementing reverse network effects), just to get ourselves of the ground.

Particularly, the danger is people who want to increase their donation rate to help projects get funding more quickly, but then decrease their donation later when it becomes too much. This is misleading to new users and reduces the incentive for them to join. "If you join, existing users will pay X more. Wait, they reduced their donations because you joined." However, I don't think there's anything problematic about this scenario:

There are 100 donors. Most want to pay more, so many significantly increase their donation level. More people join and now there are 1000 users. The donors who increased their levels are paying a lot, but they are OK with this and don't change their donation levels.

Perhaps the solution here is to implement a similar artificial upper bound on the donation rate. Here's a new iteration:

https://img.bi/#/DS4BLr3!bShevCuB79uyws4osV1LMwyoWspeNsdA5c3G_QLA

Note for bystanders: it doesn't matter how many options we end up offering or what they are, we're discussing the concept here. If we took this route I'd probably reduce to 3 options: min, max, average. Maybe with a "custom" option that's heavily de-emphasized.

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

I agree.


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


I agree.



 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


Here is my general rationale:

The idea of Snowdrift is that it has its own pace to up the game of
donation levels, depending on number of patrons.

Our primary goals as game designers are:
a) bring in as many players as we can
b) make them stick for as long as they can bare to raise donations

Whoa. This is a significant departure from my design goals (within the realm of us all having the same end goal) and is certainly why we came to opposite conclusions. Mine *originally* were:

* Bring in as much funding as we can
* Keep that funding as sustainable and stable as possible
 - Best accomplished by a large player base.

The only interesting metric is the number of players, because if there
are millions of them the donation amount gets almost irrelevant.
The machine then runs smooth without interference.

I agree in principal, but I'm concerned this is overly idealistic.

- What happens before we reach critical mass? If that takes too long, Snowdrift becomes the next Gratipay. - What about niche products that don't have the population to reach critical mass?

Having extra levels adds complexity and lowers participation and results
in less players.

I suppose it depends whether we're optimizing for funding level or users. They're the same in the long run but may differ in the short term.

The only way I see "levels" making sense is in having
an option in the user preferences to change it or people that are
interested. But not presented to all users on all projects all the time.
We only need to have a sensible default.

eg.:
we don't want people to donate peanuts for years and only pay more if
there is an ultimate superstar project

What if we compromised (that is, if you agree with me that higher funding levels might be necessary to get us off the ground faster and won't contribute to an inverse network effect -- which, of course, is very open to debate), and did something like this:

https://img.bi/#/m2UQyit!SFGxZnIuWX5351BrZDaAfAATz5RRcjozJXuLOX_9

clicking the plus gets you this:

https://img.bi/#/S9d8k0F!qKNO7ehlrdIbvI5KxvmolQz5Vkfp53Z2soAqUDqV

or an alternate UI:

https://img.bi/#/4zqCLHv!JsDaKrfRzK3me71QkTsh9wF0xKbzWT0S5vi3jCza
we also don't want people to be surprised by being underfunded
constantly because snowdrift grows quickly and many projects ask for $20
a month.

Agreed. Sensible defaults will probably go a long way here.

My conclusion is:
Keep it a simple binary decision.
Let people set up different default values in their settings but don't
advertise them playing in that arena.

_______________________________________________
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Reply via email to