implement bundles

[chadwhitacre]

A "bundle" would be a set of projects, where the user can give a fixed amount to the set and it will be split up among them according to some ratio.

---

Previous

This idea started as "support the flattr 'divide the spoils' model" (#316), which got subsumed by "implement funds" (#449). That, however, took a different turn, which ended up as the Teams feature. There's still value in the funds idea, however, so here we're bringing it back up.

Funds would be lists of percentages with a total dollar figure attached. So you might have a "Linux" fund with 50 people on it and you could set a total dollar figure that would be split according to the percentages. Funds would be public (by default) in that anyone could give to your fund, but they would be anonymous in the particulars—even for those receiving through a fund.

Say Linus has a "Linux" fund. I trust his judgment on who should get money given to "Linux" so I give $10/wk to his fund. Each week my $10 goes into that fund and gets split according to the percentages that Linus has set.

[chadwhitacre]

Bringing over from #316:

+1 from @Waldir
+1 from @ncoghlan
+1 from Justin Wilcox
+1 from @mwhooker

-1 from @lyndsysimon

[mwhooker]

This is a great idea.

I also like it because it would let me add people without worrying about spending more money.

This would dilute the pool, but I think it would be easier to get people to tip more if they could add people for free, feel good about it, and then want to increase the total give.

[waldyrious]

and then want to increase the total give.

@mwhooker that's definitely my experience. Flattr sends me monthly projected spending reports, and often use that to adjust my monthly budget if I notice the people I flattr'd are going to getting less than I would prefer to give them.

[mvdkleijn]

+1 from me too.

Someone creates a fund, adds people and other Gittip users can pay into the fund. The original creator of the fund would be the fund's manager. In fact, teams are a kind of fund already, with the only difference being that members set their own take.

Gittip could also auto-generate funds based on communities. Communities could automatically be turned into funds where every member of the community gets an automatic and equal share of the donations to that community. The only community members that would not receive a share would be the people / teams who set the "I'm a patron and politely decline to receive gifts" setting.

I think it'd probably not be too hard to add the automatic funds while parts of the UI design for team takes can be re-used for the "fund manager" approach.

(I think we should implement both flavors, not just one by the way)

[MikeFair]

I've just completed work on a distributed version of the steady state algorithm based on a directed graph view of funds that can be nested and can have cycles.

Each entry in a fund gets a numeric value expressing its weight relative to the other entries.
The values are internally relative within the fund (i.e. one fund could use 1000, 2000, and 3000; while another uses 1, 2, and 3).

The algorithm currently runs "per user"; it first downloads the entire "giving tree" for a particular user.
A user's "giving tree" is the result of bringing down the contents of all the funds in the directed graph expressed by the funds/people they give to.
(e.g. User1 -(gives_to)-> FundA -(gives_to)-> FundB -(gives_to)-> FundC -(gives_to)-> Person2, the giving tree is the superset of all entries in all paths in the entire subgraph that User1 gives to.)

After bringing down the contents of all the relevant funds/persons in the graph, it transforms the fund specific weight values into an NxN matrix of percentages between 0 and 1. It sends that matrix to a network engine listening via ZeroMQ to compute the results of the matrix. The ZeroMQ services iterate over the matrix until the percentages have been fully distributed (aka the converged stead state) and sends the resulting 1xN matrix of weights back.

It retrieves the amount of Money that User is giving this pay period (needs work) and allocates it according to those percentages (currently it uses the python-money "Money" type and its corresponding "allocate" function.

The last piece is to then build and submit the corresponding transactions for processing.

I've been using neo4j to store and retrieve the graph data; I'm attaching a screenshot of the "giving tree" I'm working with. The "user" in this case is node 149, and all the money ends up with all the edge nodes in the graph.

[chadwhitacre]

@MikeFair Does this post cover your latest private email to me?

[chadwhitacre]

@MikeFair I appreciate your work on this. We're going to need @zwn's input on this from the db side after he's done with #1549. We're also going to need to think through the user experience here. We also need to consider how #1486 plays into this. In my thinking that ticket fits with funds under the heading "evolving our money distribution algorithm." That's a hefty project that I see us tackling in earnest some time in late 2014.

[chadwhitacre]

To be honest I'm freaked out at introducing new technologies (neo4j, zeromq(!?)). Why is the status quo (Postgres) not good enough of a tool for this?

My quick take is that we want to solve #1486 first, because that applies the steady state algorithm to the current giving model. Once we land that then we can start extending the model with funds.

[MikeFair]

I can understand the hesitation on using unfamiliar tech however in this
case, SQL simply isn't a good fit for traversing graphs; and even Python
code won't express the kinds of queries that Neo4j made trivial.

ZeroMQ, Neo4j, and funds in general each solve different aspects of the
challenge for calculating community paydays. SQL could do it; but I
can't see it being a really elegant solution. SQL could still be part of
the overall solution, just not for this piece.

Using neo4j I can see a couple dozen lines of CYPHER (at most) that can
execute the payout calculation algorithm that would
implement "funds",
matching payments,
using the givers internal balance,
support prepaid accounts and prorating those payouts over many weeks,
refusing to accept tips for accounts that are only givers and routing those
funds elsewhere,
Campaigns that require a minimum funding amount by a specific date,
Not giving a recipient more money than 10% beyond their weekly earning
target and redirecting those funds to other recipients,
and likely several other things that can be determined simply by looking at
the state of the graph.

The front end web application would be executing simple CRUD operations on
the object properties in the neo4j database to maintain all that
information. (And maybe the neo4j company would even host it and help us
maintain it.)

The Python payday code then becomes a loop driver to iterate the query
until the steady state has converged (aka no more nodes are being updated).

As for doing #1486
#1486 first;
I see the neo4j Cypher Query approach that's running the payday algorithm
can handle that really easily. It could track the negative balance and
reduce it as money comes in, issue the charge request, then distribute the
money if it succeeds (but I really don't think that's the right solution
despite that being what was requested); It could do what it does now and
charge the user based on the 'beginning balance' at the start of payday
(and yes that means there's going to be a balance - and educate people on
why that's a good thing because it creates predictably for those who are
supposed to receive the money; the system can tell them about how much
money is in the bank scheduled to be delivered).

Encouraging people to prepay their accounts is honestly the real solution
here. Let them know that by prepaying their accounts we're providing
predictable income for those who are receiving them. You can obviously
change your tips at any time, but it's useful to set yourself up to give at
whatever level you're comfortable giving at and let the system prorate that
out to whomever you've identified to receive it. Fewer, larger inbound
transactions creating a more sustainable future for those who would like to
earn regular income this way.

Other tickets I can see that either go away or get significantly easier
include:

#1486 (funds distribute a prorated amount of whatever balance a user has -
it makes no assumption about how much money is actually in someone's
balance; it can just deal with whatever is actually there),

#1383, minimizing escrow (that just gets closed; it's simply not a good
idea; hosting lots of in transit funds is the only viable future for many
reasons); we might try exchanging money out to connected bank accounts if
it looks like the money is just accumulating somewhere; but ensuring it
gets redirected is the real solution to that.

#113 allow people to prefund their accounts (that's a great idea; and
totally incompatible with the idea of minimizing in transit funds);

#1660, A fund is an allocation algorithm; an allocation algorithm can be a
pluggable thing.

#1594, again anything mission oriented can be a fund which can be allocated
to; kind of like a campaign

#1609, that's the basic/main allocation algorithm/strategy of what this is

#1592, this is an allocation algorithm that a fund/team can subscribe to;
code it up as a bot, that bot will get asked what the weights are supposed
to be come payday (I believe this would require implementing some Java
hooks into the Neo4j database, but I think/know it can be done)

#1589, A "Team" is created as a Fund, the fund has an allocation algorithm
behind it, when people use that fund to give it splits up their money
according to the team's allocation algorithm

#1290, a "Team" is a Fund that contains people; a list of weights doesn't
give anything; it routes packets (of money) according to an allocation
algorithm

#1351, someone with permission to do so simply removes all other people
from the fund

#878, that's a description of a fund

#696, the tags are funds and the tag cloud scores get stored in a fund as
weights (or is implemented via a bot that responds with the dollar amounts
to give to each person)

#652, that's a fund allocation algorithm

#649, the graph of all funds and average allocated weekly pay-in amounts

#279, again the interest is credited to a "fund" which handles the
allocations

#209, A campaign is tied to a fund and is where the progress gets tracked
and a property of the campaign can be "minimum amount required before
release" and "expiration date"

#1033, Someone transfers the amount they would like to make available for
matching from their own balance to a "matches" relationship connected to
the fund. Money flowing into the fund "triggers" a release from all its
"matches" relationships

#10, related to #649; #11; #113; and #777. The ability to create
predictable income;

On Mon, Dec 2, 2013 at 11:52 AM, Chad Whitacre [email protected]:

To be honest I'm freaked out at introducing new technologies (neo4j,
zeromq(?)). Why is the status quo (Postgres) not good enough of a tool for
this?

My quick take is that we want to solve #1486https://github.com/gittip/www.gittip.com/issues/1486first, because that applies the steady state algorithm to the current
giving model. Once we land that then we can start extending the model with
funds.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1493#issuecomment-29651230
.

[bruceadams]

Thank you @MikeFair! This is a great write up. I'd love to understand the neo4j approach you are talking about, but I'll admit that I don't have the bandwidth to think about it right now.

[zbynekwinkler]

I don't have the bandwidth to think about it right now.

Same here. While SQL might not seem like a good way to implement graph traversal, Python is flexible enough to do so. Our whole db is around 150MB and most of it is user_info saved from elsewhere services. Our graph is currently so tiny (about 2.9k active users for all time) that we do not need new tech to handle it. It all fits into a memory and it will for a quite some time. New tech takes developer bandwidth which is something we are currently really short of.

[chadwhitacre]

+1 from @dominic on Twitter (assuming funds could be public, so you could invest in someone's "Whatever" fund).

[chadwhitacre]

IRC

[MikeFair]

There's another opportunity/aspect/thought model/conceptual vision to
consider.

Instead of thinking of them like something that money gets "sent to" like
some sort of magic money routing box "out there"; think of them as
something you can "copy in" or "subscribe to" to help you route the
resources that you're gifting.

You don't send your money out to the fund; you suck in the fund's opinions
and merge it gets merged into your own giving tree. Think of it like
whenever the fund changes it initiates a "pull request" to your giving
tree. By accepting this pull request you allow the fund permission to
populate gift amounts into your portfolio.

Funds are people's opportunity to publish their ideas about what they would
like to see supported. Using this model, anyone can publish a fund about
anything; people can then track whichever funds they think are important
but at all times it is and remains the tips they are sending out.

On Wed, Apr 2, 2014 at 3:33 PM, Chad Whitacre [email protected]:

IRC https://botbot.me/freenode/gittip/msg/12879301/

Reply to this email directly or view it on GitHubhttps://github.com//issues/1493#issuecomment-39392464
.

[chadwhitacre]

+1 from @dstufft on Twitter.

[chadwhitacre]

Follow-up from @dstufft:

While I think that’s a good idea, it still requires me to pick a dollar amount.

[chadwhitacre]

Hey @Changaco, I am reminded by @carsomyr that we should take this thread into account when rewriting payday.

[chadwhitacre]

+1 on HN:

The reason my own donation is shitty is because I have to figure out who to donate to and how to donate to them, and then I end up having to maintain as many channels for cash as I have things to donate to. Can't you just offer me curated funds where percentages of my monthly tithe go to a range of things that are often supported together, and you guys just keep it updated?

[chadwhitacre]

+1 on HN:

They could let the donor set an optional maximum monthly contribution. Of that maximum contribution, the donor could set how much of it goes to each tip. The giving page seems like a good place to put such a thing.

[chadwhitacre]

+1 on HN:

I wish there was some way to donate to a group of people that was automatically managed by you guys (or crowd-sourced if you can make that work).

I wouldn't mind giving a little bit each month, but I don't really feel like searching for specific users that do work I want to support, and then checking back every few months to make sure they still are.

With follow-up:

The Neo4j solution is really an ideal solution for automating some of this stuff. I beg you not to dismiss it out of hand because of lack of familiarity...

[kybernetikos]

I have also found that often I want to give to the people working on products that I like to use, but it's not clear the best way to do that (their twitter account? their github organisation? their main devs?). Perhaps the funds system could help with this too?

As an aside, can funds potentially include other funds?

[Changaco]

Tagging as "Ready to Start" since this didn't make it into the payday rewrite (which was complicated enough without it).

Note that implementing this in neo4j probably isn't an option, because I'm not familiar with it and I don't think any other member of the Gratipay team is. It can and should be done in pgSQL.

Also note that #2664 should probably be implemented first.

[chadwhitacre]

+1 https://gratipay.freshdesk.com/helpdesk/tickets/1705

It would be great if the giving page could be customised. Instead of one long list, the ability to have several customised lists. i.e. “Tips to Team”, “Tips to Members”, “Tips to Organisations We Love”, etc. This way we can have greater transparency over how we distribute our tips.

...

As long as the funds have the option to show teams and individuals within the fund who receive.

[mattbk]

Recently "bundles" have come up as a variation of this, but they wouldn't be public.

[chadwhitacre]

@dmk246 suggests the shopping cart model. Add projects to yer cart and then check out.

[chadwhitacre]

Closing in light of our decision to shut down Gratipay.

Thank you all for a great run, and I'm sorry it didn't work out! 😞 💃