implement funds #449
The idea here it to provide a way to lump individuals together into groups and projects for funding purposes. A "fund" here is a set of weighted percentages for individuals and other funds (funds can be nested). Then we use these funds as levels of indirection when shuffling money around each week on payday.
Was: group tips together for simultaneous adjustment
I believe this is what @joelmccracken is asking for on #434. The coarse-grained case would be adjusting all tips at once (#448). This ticket is for grouping tips together so that you could adjust 10 tips at once without touching the other 20. The language that Joel used was "a single tip covering multiple people."
The text was updated successfully, but these errors were encountered:
Gittip users can create one or more "funds" (as I'm calling them). A fund is a mapping of participant_id to integer weight:
The part of the Gittip profile page where you see everyone you're giving to ... that becomes a UI over this data structure. Then in the API (#462) we have this as an endpoint that can be posted to by the Gittip UI as well as by third-party applications. Then, we allow for funds to be the keys as well:
One thing to tease out is the interplay between absolute dollar amounts and percentages. Another is how to keep the damper on volatility.
Next step for me here is some paper prototypes ...
Users have zero, one, or more funds. We create a "default" fund for them when they register (cf. #489). In the UI we want there to be a default fund, to streamline the simple case where a user has a single fund. (Whether we enforce a one-fund minimum under the hood or allow the user to drop to zero funds is an implementation detail.)
All funds are public. When I go to a profile page I see a list of funds that the user has created, as well as the weekly dollar amount being given to each fund. These are also shown on community pages (#496). Funds are anonymous in that the allocation of each fund is not public. Users can't be part of their own funds. Non-self users and other funds can be part of funds.
Users allocate dollar amounts to funds. They no longer allocate dollar amounts directly to other Gittip accounts.
Each payday, the fund graph is reduced to dollar amounts from one account to another.
This sounds legit to me. I did a double take on "fund can't contain creator". I understand why, but I would have initially suspected that JKM would create a Django fund and put himself in it (though he likely wouldn't, it serves as a good example). Skipping it seems to remove some of the possible abuse potential of having someone tip a fund, then dropping everyone out but you, etc.
I think this is a clear move in a solid direction.
Oh wow, this sounds confusing. So a group fund can pay to other group
On Fri, Jan 18, 2013 at 1:07 PM, Justin Abrahms email@example.com:
@justinabrahms Yeah, designing the algorithm for computing concrete gift amounts each payday from the graph of funds is going to be an interesting challenge (cf. https://github.com/zetaweb/www.gittip.com/issues/129#issuecomment-12341021). :-)
@joelmccracken My thought was a fund is a set of percentages:
That means: "Give 10% directly to the Gittip accounts of Guido, Adrian, and ACDC, then distribute 40% amongst whatever Gittip accounts are represented by Adrian's 'Django' fund, and 20% amongst whatever Gittip accounts are underneath Guido's 'Python' fund, and the remaining 10% amongst accounts under Linus' 'Linux' fund."
The simple case is that you'll have a single fund—you won't even have to know the word "fund" to use it. It'll just look like a set of percentages as above, and then a big fat "$100.00" at the top, which is the total amount you're giving each week; it will be split up according to the percentages. On payday we'd do a lot of number crunching to determine exactly where your money goes.
Does that make any sense?
it does! Very good =D
On Fri, Jan 18, 2013 at 3:57 PM, Chad Whitacre firstname.lastname@example.org:
I'd like to allow creators to be a member of their own funds for a number of reasons including A) the ease with which a creator could work around such a restriction, B) the difficulty of implementing such a restriction at this time, and C) This kind of thing is more 'one man's opinion' versus functional requirement and therefore it's better to give the gifters/upstream funds a tool/setting to express such an opinion. For instance, a checkbox that says "This fund does not allocate to the creator's of the funds it contains" or a user that is able to mark "Reallocate tips for the creator's of funds" in their profile.
Aside from the weight an item in a fund could have other settings (and this likely should go in as a separate GitHub ticket to be worked on after funds themselves are initially working).
With an upper bound capability, a creator could allocate to themselves but set the upper bound to be "when user's doneness reaches 100%" which is a way of saying "Do not allocate any more than their target amount".
These bounds are cumulative to the total amount the user is to be tipped that payday.
I'd like see the fund's contents to be public rather than private.
On larger projects I fully expect there to be multiple versions of a fund for the same project because people have different opinions about who the important people are and how important they are relative to the other items in the fund.
Being able to see the contents of the fund and hearing their creator's describe how they are constructed is an important aspect of the ongoing nature of selecting which funds to give to.
A user's specific allocations would be private, other people can't see who specifically is giving to what fund as that's more about personal choices, but what would remain visible is the total aggregate amount that each fund is receiving.
You're right that these go together: creators aren't allowed to be members of their own funds precisely because funds are private.
Sure. If I'm Linus, I can create a shadow account and include that in my "Linux" fund, and then when people give to my Linux fund I'm able to recover some or all of that for myself. The restriction on creators in their own funds is a soft constraint intended to steer the growth of the community, not a hard line. We wouldn't even make this a terms of service violation; it'd be an acknowledged workaround: "If you want to receive money from your own fund, create a second account." We want to discourage people from being greedy on Gittip, but the point is that we trust Linus. The "no creators" constraint removes 99% of the burden of proof from Linus; his reputation for trustworthiness easily makes up the other 1%. And if he really, really wants to include himself in his own fund, he can.
Not sure I see this one. Does this refer to some constraint with the CouchDB option? If so, the answer is that, if at all possible, user experience drives technology, not vice versa.
It's part of the defining character of Gittip that gifts are anonymous in the particulars (we had a ticket for making tips non-anonymous, #326; I just closed it). Private funds fit that character better than public funds. If we try to support both public and private funds we muddy the product.
I'd like to see this work the other way around: Just as Linus is free to create a second account, he is free to disclose what his funds contain. Disclosure is not a violation of Gittip's terms of service, but Gittip is not going to do it for you.
If that's true then it seems like when we roll this out we'll expect to see a) demand for public funds, b) funds that disclose elsewhere do better than funds that don't, c) third party tools to implement public funds on top of Gittip. For now, I'd like to move forward with private funds, depending primarily on the reputation of the fund managers to drive fund selection. We can revisit as needed once we have this out there for a while.
A user's Basket is clearly a private affair.
So in this model, what's a fund then?
A Fund (and the nesting of funds) is an organizational tool to aid us in the process of selecting the people we're going to give to and how much we're going to give to each person.
A Fund is a mechanism to, in essence, create a function call that expands one label in our own basket into a list of people and amounts.
In this model none of us give anything to Linus' fund.
Since the model is that it's actually the user's basket that is executing some allocation function to figure out who to give to, this makes these allocation functions more akin to source code in that respect.
This then creates a very consistent story of what's happening on payday that exactly matches what's already happening today.
Since I've subscribed some fraction of my giving to Linus' fund, then what happens on payday is my basket executes the 'Linus' Linux Kernel Fund' allocation function which expands to a list of people that I'm going to give to and how much I'm going to give them this payday.
I'm still the one ultimately allocating those direct gifts, I'm using Linus' opinion as part of my selection process.
The anonymity of where the money came from to the recipient in this point of view remains intact.
It could be created by anything, a person, a committee, the outcome of some election, a computer algorithm; anything that is capable of creating a list of names and weights. This makes it really hard to determine who the creator is in some of these cases (and what's driving the difficulty of enforcement).
For example, if Debian chooses to hold a semi-annual election to reconstruct the contents of the Debian Allocation Fund each period, we're obviously not going to say that all the people who voted can't be in it (and how would we know who they were anyway), it makes sense the sitting president of Debian would likely be in the Fund despite that's also the most likely person to take responsibility for publishing the fund...
What gives a fund power is people subscribing to it and pulling the function/algorithm that it represents into their own basket and using it to make their allocations with.
If people think the creators, however the chooser defines creator, shouldn't put themselves into their own funds, they won't subscribe to or use that person's allocation algorithm thereby removing power from that Fund.
As the Funds contents are public in this model, if someone didn't want to give to a Fund's creator, the person would be able to create their own new Fund and construct it like this:
Now instead of subscribing directly to the other fund, they subscribe to their own version of it.
I haven't discussed the pipelining of Fund transformations yet as I felt it was way too early in the implementation to bring it up.
Like with our source code, I envisioned there would be a whole suite of tools to aid us in putting together these Funds. Allowing people to start with someone else's list of names (source code) and then apply a series of transforms (like a series of patches/commits/XSLTs) as a pipeline or build process an integral part of the equation to make it so that we can easily take other people's ideas for where to give and transform it to make it our own.
It's the same thing we do with our code, applied in a new context.
I've somewhat addressed that by showing how the Funds are functions people begin with, not direct allocators.
Instead of keeping the Fund's contents private keep the amounts that Fund is responsible for allocating private.
So instead of a big $100 at the top of the Fund (because we aren't actually tipping a fund, the fund is a function people are using to figure out who and how much to tip), perhaps we assign some impact scores that say something about the fund's popularity, influence, and impact that it's having within the social framework.
Perhaps a "download count" or "number of subscribers". This keeps private how much came from where and to where and is simply saying how popular this Fund is for people to use in their allocation algorithms.
@mvdkleijn Right, funds ended up morphing into Teams (via "open groups"). Down the line we can revisit the idea of funds as originally described on this ticket, but I don't want to get into that right now. Let's stay focused on cleaning up what already exists.