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 <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.
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. > > 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. >> 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. >> 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. > - 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. >> 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 >> Discuss@lists.snowdrift.coop <mailto: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 > -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
