implement funds

[chadwhitacre]

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."

[chadwhitacre]

After conversations with @MikeFair in email and IRC, I'm now looking at this as the answer to the question of aggregating individuals into groups on Gittip.

!m @joelmccracken

[chadwhitacre]

Gittip users can create one or more "funds" (as I'm calling them). A fund is a mapping of participant_id to integer weight:

{ foo: 1000
, bar: 400
, baz: 200
, buz: 10
 }

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:

{ foo: 1000
, "bar/baz": 400
, baz: 200
, buz: 10
 }

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 ...

[chadwhitacre]

Just got off the horn with @MikeFair. He had the interesting idea of implementing this using CouchDB. We would store funds as full json docs in there, and use Couch's map-reduce implementation to compute dollar amounts from there. He's offered to spike that out for us. Reticketing as #488.

[chadwhitacre]

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.

Issues subsumed by this one: #27, #55, #94, #216, #316, #327, #372, #434, #448.

[justinabrahms]

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. 👍

[chadwhitacre]

Exactly, @justinabrahms. Presumably Jacob's Django fund includes your Django fund, which includes Jacob, etc.

[justinabrahms]

Oh, interesting. You're suggesting that these can be nested. Are the weights accumulative? Something to watch out for is that you limit the depth of these transitive tips, else you'll need to ensure its not a cyclical graph. :)

[joelmccracken]

Oh wow, this sounds confusing. So a group fund can pay to other group
funds, not only other individuals?

On Fri, Jan 18, 2013 at 1:07 PM, Justin Abrahms [email protected]:

Oh, interesting. You're suggesting that these can be nested. Are the
weights accumulative? Something to watch out for is that you limit the
depth of these transitive tips, else you'll need to ensure its not a
cyclical graph. :)

—
Reply to this email directly or view it on GitHubhttps://github.com/zetaweb/www.gittip.com/issues/449#issuecomment-12434005.

[chadwhitacre]

@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:

40% Adrian Holovaty -> Django
20% Guido van Rossum -> Python
10% Linus Torvalds -> Linux
10% Guido van Rossum
10% Adrian Holovaty
10% ACDC

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?

[joelmccracken]

it does! Very good =D

On Fri, Jan 18, 2013 at 3:57 PM, Chad Whitacre [email protected]:

@justinabrahms https://github.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. #129https://github.com/zetaweb/www.gittip.com/issues/129#issuecomment-12341021).
:-)

@joelmccracken https://github.com/joelmccracken My thought was a fund
is a set of percentages:

40% Adrian Holovaty/Django
20% Guido van Rossum/Python
10% Linus Torvalds/Linux
10% Guido van Rossum
10% Adrian Holovaty
10% ACDC

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?

—
Reply to this email directly or view it on GitHubhttps://github.com/zetaweb/www.gittip.com/issues/449#issuecomment-12440694.

[chadwhitacre]

[MikeFair]

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.

2. One of the things I would fully expect to see would be Chad's name in the GitTip fund. Something would seem off if it wasn't there.... (though if I am reading the idea right, the contents of these funds are a big black box atm.)

3. Another tool that comes into effect to help with the actual dollar amount allocation of these funds is the user's "target tip amount" (assuming they've set one).

The formula:
[User's Target Tip Amount] / [Total Amount of All Tips Given] = [User's Percentage of Doneness]

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).
Two of these setting I expect to be a hard lower and upper bound for how much to give.

For instance,
"Lower Bound = If this minimum amount cannot be allocated then allocate nothing and redistribute the weight to the rest of the fund"
and
"Upper Bound = Any amount allocated over this amount should be redistributed to the other items in this fund"

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.
This means that if a single user receives tips through many projects or sources, (and assuming the upper bound setting of 100% doneness is in effect) then on payday the user will receive up to their target amount and no more. Any excess amount will get redistributed to the other items.

[MikeFair]

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.

[chadwhitacre]

@MikeFair

I'd like to allow creators to be a member of their own funds.
I'd like see the fund's contents to be public rather than private.
(though if I am reading the idea right [...])

You're right that these go together: creators aren't allowed to be members of their own funds precisely because funds are private.

the ease with which a creator could work around such a restriction

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.

the difficulty of implementing such a restriction at this time

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.

C) This kind of thing is more 'one man's opinion' versus functional requirement

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.

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.

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.

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.

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.

[chadwhitacre]

@MikeFair

3. Another tool that comes into effect [...]

I'm reading this as unrelated to the matter of funds being private (correct me if I'm wrong). This gets into the details of computing amounts from funds on payday, right?

[MikeFair]

Four things:

1. There's a distinction between a user's "Basket" (where they personally are giving) and a "Fund" (some opinion/allocation function other people use to select where to give).

A user's Basket is clearly a private affair.
A Fund/Allocation Algorithm I consider a public affair.

2. The model I'm working within is that we are always doing direct person to person gifts.
   We do not ever give to funds, we are always giving directly to other people.

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.
We use the allocation function Linus published (called a Fund) in the execution of our own allocation function.
This is conceptually no different than executing other's published algorithms in our own computer systems.

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.
This remains consistent with exactly what's already happening right now, people choosing people to tip.

3. Relating to creator's not being able to put themselves into the fund.
   A fund can come from anything and be about anything.
   It's not only the simple case that a single individual creates the Fund.

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:
"Start with the Published fund I don't like because the creator is in there and apply this transform to remove the creator."
Once published, other people could subscribe to that version of the Fund if that was their wish.
(In fact I've always envisioned that such a transform (think of it like an XSLT), in and of itself, would be a popular published code snippet to be applied by people in many cases.)

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.

4. All that said, it seems the main concern here is having people be able to figure out how much they are getting through a particular fund somehow reducing the anonymity of the gifts to the recipient.

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.
This way everyone can see what these Funds contain, but not how much is going where as a result of that.

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.

[chadwhitacre]

This shit is released, people! Will reticket ... everything else I didn't do yet. :)

[mvdkleijn]

Sorry for commenting on a closed issue... I'm confused. How are funds implemented? Or are Teams supposed to be funds? I don't see options to donate to communities and I don't see funds in the UI anywhere. The closest thing I can find is Teams?

[chadwhitacre]

@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.

[chadwhitacre]

This took a left turn into Teams. Reviving the original proposal as #1493.