On Wed, Oct 21, 2015 at 12:41 PM, Aaron Wolf <[email protected]>
wrote:
On 10/21/2015 08:54 AM, Stephen Michel wrote:
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 <[email protected]> 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.
The entire issue of "the project is so successful, how do we keep
letting poorer patrons participate" is not the topic here. Our goal is
to get to where that is our problem, and we have easy solutions
discussed at https://snowdrift.coop/p/snowdrift/w/en/limits
We do not need to get sidetracked by that here.
Agreed. I was only bringing it up in the context of, "Here's how we
handle that issue on the low end. Does it make sense to do the same 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.
Indeed, one goal we can certainly accept is that we encourage people
to
donate more than they initially predicted they would because they are
so
happy to be part of achieving something greater than they thought was
possible. So, they end up saying, "oh, I see now what a difference,
we're all making, I'm willing to keep my pledge even though it's
higher
than I predicted it would get".
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.
I still like the idea that we include "more options" per project and
work to figure out the right approach here, emphasizing to early
patrons
hat things are being tested and are in flux. I think we *do* have some
time period where people understand that the options aren't set in
stone
and will give us some leeway if we present it that way. We really
*should* get to where we can run real live functioning site and still
be
in testing. The only thing I really oppose is the suggestion that we
can't do that sort of testing. We *can*, as long as everyone
understands
that this is what is happening and the particular numbers and levels
are
in early-testing, beta state.
I think we can have a single default base-level pledge button and
still
offer a "more options" link per project that has a few levels to
choose
from. And we will need to track the results, see how much people use
it,
follow up with people, communicate with them, carefully see how it
goes
and actively work with people to get their impressions, answer
questions, and tweak the options as necessary.
I still like the idea of an average/recommended option. I'm not sure if
I like it as the only option. But I do like a single button with 'more
options' below.
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.
Yes, we want to maximize funding, but if there are two scenarios with
similar/same funding, we prefer the one with the greater number of
patrons. **And we want to prefer sustainability and lower initial
funding
over good initial funding that is unsustainable.**
Emphasis mine. It is really important that we all get on the same page
as this. I'm not sure that unsustainable but higher initial funding is
terrible. If we never take off and people start seeing us as old news,
we *will* not take off.
If we take off, as we become more popular we can adjust to push towards
sustainable funding on the fly.
Venture capital isn't sustainable, but people do it all the time
because it often takes an investment to get off the ground. That's what
I'm saying.
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.
Snowdrift will never be Gratipay for a wide range of reasons, and I
don't think Gratipay's struggles have to do with reaching critical
mass.
I just meant it as an example of a project that never took off and now
never will because it's old news.
- What about niche products that don't have the population to reach
critical mass?
Niche projects, especially highly costly ones, are a *real* topic that
we should address. I could imagine setting higher minimums or at least
different suggested levels for niche projects. I definitely think the
difference between expensive niche projects with a core set of strong
supporters is a different thing than the most generalized widely-used
things, and I think we *need* to be able to deal with that. The
questions here aren't easy to solve, and I think they *will* take some
testing.
Agreed. However I'll also note that even though I'm the one who brought
up niche projects, snowdrift isn't a niche project and all we care
about for beta is, "what's the best way to implement the mechanism for
snowdrift," so let's table this conversation?
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.
In the short term, we are not going to optimize for funding in ways
that
hurts the level of user adoption.
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
As I said, I like the "more options" style myself.
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
[email protected] <mailto:[email protected]>
https://lists.snowdrift.coop/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
https://lists.snowdrift.coop/mailman/listinfo/discuss
--
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
_______________________________________________
Discuss mailing list
[email protected]
https://lists.snowdrift.coop/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
https://lists.snowdrift.coop/mailman/listinfo/discuss
