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
Best,
Aaron
--
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
