On 09/23/2015 02:09 PM, Stephen Michel wrote: > > > On Wed, Sep 23, 2015 at 11:39 AM, Aaron Wolf <[email protected]> wrote: >> Hi Stephen, We're all on the same page already! > > I actually had read the latest mechanism before making my proposal, and > I think it's very good, which is why they're so similar :P > > The substance of the difference is in how the final automated payout is > handled. While the change is small, I think my proposal actually has > significant benefits. I was really tired when I wrote this last night > (note to self: write when you're awake) and I don't think I provided > enough context for why this would be an improvement. So, I'll try to do > that (and a little clarification) now. > >> On 09/22/2015 11:23 PM, Stephen Michel wrote: >> >> _This email has two things:_ 1. Statement of our goals relating to >> the defunding mechanism, so we have an agreed-upon base to have a >> discussion from. 2. Proposal for simplified mechanism to >> accomplish those goals. *1. Goals of a defunding mechanism:* - >> Encourage users to deposit more funds in their account. - Provide >> users with an easy way out (if I decide to leave the coop, it >> sucks to have money stuck in my account) - Should be easily >> understandable and intuitive. >> >> The idea of withdrawing your funds when you leave is actually likely >> to be something we cannot legally support. If we actually go with the >> idea that the funds we hold are in fact still your money, we will >> almost surely be considered an illegal money transfer service. > > I didn't mean to propose we allow users to withdraw money. Rather, that > we must have a way for users to distribute all remaining funds -- let's > call that "zeroing your balance". The current mechanism does this > automatically; mine does not, so I wanted to be explicit about it as a > requirement. > >> Thus, we have tentatively concluded that we only have two options: A. >> All funds are donated immediately when deposited, pledges count as >> voting for which projects get the funds. (This really won't discourage >> deposits that much. If people support FLO in general, then the idea >> that they can't get back their $10 is not a big deal, they can still >> deposit incrementally). B. Charge in arrears (we don't hold funds at >> all, we just charge people once donations reach a threshold that is >> worth making a charge). This means if people leave, we either make >> final uncomfortably low charges or lose some amount of cents that >> would have been their final donations but they didn't add up to enough >> to be worthwhile. Neither of these are awful, and they really are the >> only options. Details: >> https://snowdrift.coop/p/snowdrift/w/en/transactions > > Missed that page. It includes a line about zeroing your balance: > > "When closing accounts, patrons may either immediately split funds to > select projects or just donate all to the Snowdrift project." > > I have two additional suggestions. > > *Important: *There should be a way to zero your balance without > completely closing your account. If I'm going through a tough time > financially and can't afford to donate at the moment, but intend to pick > up where I left off (but, I don't want my deposited funds to "go to > waste" in the meantime). > > *Most Intuitive behavior (imo): *"select projects" should be the same > projects & ratios as I was previously donating to. Perhaps when we > launch there should be a way to pick how "your" money is distributed > when you zero your account, but I think for the MVP it makes sense to > only have one option (this one), which also allows for a > close-to-one-click "zero my balance" button. > >> *2. Proposed new mechanism* * * - An account can only have two >> states: /Active/ and /Inactive./ - When an account's balance falls >> below the amount required to pay all of their outstanding pledges >> in full, it becomes /inactive./ - Pledges are now in terms of >> /active/ patrons. (when an account becomes /inactive, /other >> patrons no longer match for it.) - Owners of inactive accounts >> have three options: 1. Lower their pledge amounts until balance > >> payout 2. Add more money so that balance > payout 3. "One-time >> donation:" Donate to each project, immediately, a percentage of >> the money remaining in the account, so that when everything is >> paid, the user has $0 left in the account. This does NOT make >> their account become active or cause others to sponsor their >> shares (their acct is still /inactive./ / / Now we only need 3 >> notification options: Account Balance is low (next payout will >> cause account to become inactive) | Not Required Account becomes >> inactive | Required Payout Occurs | Not Required Thoughts? >> >> We're already on it! We already decided to drop the whole idea of >> partially active accounts and "shares". Bryan has been working on >> implementation of this simplified approach. My thought and proposal is >> almost *exactly* yours with a couple minor differences. >> When total funds < total pledges, my version is: if this situation >> gets all the way to a pay time with no adjustments in funds or >> pledges, then the system automatically does the split up among >> projects. And in my view, we *still* count that patron for this last >> time, even though the donations are less than their full pledge. > > Clarification on my motivations: > > *Problem: Conflict of interest: users have an incentive to let their > account balance drop to 0 before depositing more funds in the > account.* When I'm underfunded, I am being "matched" at a higher level > than usual, since nobody else drops out just because I'm not "pulling my > weight." We want incentives to be aligned (towards continuing to donate). > > /Barely-related tangent: I actually like the system of donating per > patron vs the SUM(lg(shares)) method, because it encourages patrons to > donate smaller amounts to many different projects, helping to avoid the > "donating to a large project is a better use of my money" problem./ > / > / > *Problem: can't anticipate users: We don't know how a user will want to > distribute their funds when they cannot perform a full payout. *Some > users may want to distribute at the same ratio they have been. Other > users may want to decrease evenly but never below the minimum monthly > donation (my personal choice). Others may want to give all their money > to their favorite project (us!). There are a lot of reasonable options, > it's hard to know which one the user will want, and we don't want to > "spend" a user's "money" in a way they *don't* want, because that > creates bad experiences that will drive people away from the site. At > the same time, we don't want to offer too many or too complex options > that the user must figure out, or we will drive away users who just want > to support their favorite project without thinking too much / doing math. > >> The notification details you mention are exactly the plan. > > Not quite -- my version drops one of the notifications. Here's how; > > I'm looking at "budget notifications" on this page: > https://snowdrift.coop/p/snowdrift/w/en/mechanism#fnref3 > > Formally stated, we need an optional notification of pending account > state changes, and mandatory notification when account state changes > actually happen. > > *Current Possible States & Action taken* > > 1. Funded --> Pay out normally > 2. Underfunded --> Pay out a fraction > 3. Inactive --> Do not pay out > > *My version:* > > 1. Funded --> Pay out normally > 2. Underfunded --> Do not pay out > > Therefore, we can drop the notification for "your account balance ran > out," because in terms of automatic funding there is no distinction > between "underfunded" and "no funding." This is also why a "zero your > balance" function is important, so a user isn't left stuck in a non-zero > underfunded state. > > Fewer states & fewer notifications => easier to code, fewer edge cases, > better user experience all around. > >> You can check with Bryan about the status of his updating all the code >> to implement this new simplified approach. Here's the discussion: >> (looks like we didn't think to make it a ticket per se, although it >> was known to us that this is Bryan's priority work to focus on >> implementing this) >> https://snowdrift.coop/p/snowdrift/w/en/mechanism/c/3419 Cheers! Keep >> the ideas coming, you're clearly thinking well about the issues we're >> facing and how to design this well. > > Great minds think alike.... > > Cheers, > Stephen >
In short: I like it. I think you have some good thoughts. I'm basically read to accept your proposal and suggest we just do it (as long as Bryan and others seem fine with it). A couple minor points though: We would want a policy that underfunded (i.e.) inactive accounts automatically get zeroed after some amount of time. While you're right about the "let funds get to zero to underpay while being counted still" issue, and zeroing out should be a distinct action we offer *as well*, in the existing proposal, people couldn't keep counting as underfunded. If you ever zero-out, then you need to at least put in funds for three-months of pledges per our buffer requirements. But I certainly see value in saying, "you have to keep up the REAL pledge you placed or you don't count." In conclusion, let's just go with your suggestions for the prototype. I like them, and they are simple and easy to explain. Either you are all good or you lack funds and don't count. And if you have left-over inadequate funds, you can either adjust things to be good again, or you can zero-out. Fine. Sounds good to me! Thanks -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Discuss mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/discuss
